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ABSTRACT 



A system, method and article of manufacture are provided 
for managing an environment in a development architecture 
framework. Service of a system is managed based on service 
level agreements and/or operations level agreements. A 
plurality of system management operations are performed. 
The system management operations include start-up and 
shut-down operations, back-up and restore operations, 
archiving operations, security operations, and performance 
monitoring operations. Service is planned in order to antici- 
pate and implement changes in the system. 
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SYSTEM, METHOD AND ARTICLE OF 
MANUFACTURE FOR MANAGING AN 
ENVIRONMENT OF A DEVELOPMENT 
ARCHITECTURE FRAMEWORK 

CROSS REFERENCE TO RELATED APPLICAnONS 
This application is related to U.S. patent applications 
entitled "A SYSTEM, METHOD AND ARTICLE OF 
MANUFACTURE FOR BASE SERVICES PATTERNS IN 
A NETCENTRIC ENVIRONMENT* (Ser. No. 09/387,653, 
filed on Aug. 31, 1999) and "A SYSTEM, METHOD AND 
ARTICLE OF MANUFACTURE FOR MAINTENANCE 
AND ADMINISTRAHON IN AN E-COMMERCE APPU- 
CAnON FRAMEWORK" (Ser. No. 09/388,910, filed Aug. 
31, 1999) both of which are filed concurrently herewith and 
which are incorporated by reference in their entirety. 

FIELD OF INVENTION 

The present invention relates to development architecture 
frameworks, and more particularly to managing an environ- 
ment of a development framework. 

BACKGROUND OF INVENTION 

An important use of computers is the transfer of infor- 
mation over a network. Currently, the largest computer 
network in existence is the Internet. The Internet is a 
worldwide interconnection of computer networks that com- 
municate using a common protocol. Millions of computers, 
from low end personal computers to high-end super com- 
puters are coupled to the Internet. 

The Internet grew out of work funded in the 1960s by the 
U.S. Defense Department's Advanced Research Projects 
Agency. For a long time, Internet was used by researchers in 
universities and national laboratories to share information. 
As the existence of the Internet became more widely known, 
many usees outside of the academic/research community 
(e.g., employees of large corporations) started to use Internet 
to carry electronic mail. 

In 1989, a new type of information system known as the 
World-Wide-Web ("the Web") was introduced to the Inter- 
net. Early development of the Web took place at CERN, the 
European Particle Physics Laboratory. The Web is a wide- 
area hypermedia information retrieval system aimed to give 
wide access to a large universe of documents. At that time, 
the Web was known to and used by the academic/research 
community only. There was no easily available tool which 
allows a technically untrained person to access the Web. 

In 1993, researchers at the National Center for Supercom- 
puting Applications (NCSA) released a Web browser called 
"Mosaic" that implemented a graphical user interface (GUI). 
Mosaic's graphical user interface was simple to learn yet 
powerful. The Mosaic browser allows a user to retrieve 
documents from the World-Wide-Web using simple point- 
and-chck commands. Because the user does not have to be 
technically trained and the browser is pleasant to use, it has 
the potential of opening up the Internet to the masses. The 
architecture of the Web follows a conventional client-server 
model. The terms "cUent" and "server" are used to refer to 
a computer's general role as a requester of data (the client) 
or provider of data (the server). Under the Web, 
environment, Web browsers reside in clients and Web docu- 
ments reside in servers. Web clients and Web servers com- 
municate using a protocol called "HyperText Transfer Pro- 
locoT* (HTTP). A browser opens a connection to a server and 
initiates a request for a document. The server dehvers the 
requested document, typically in the form of a text document 
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coded in a standard Hypertext Markup Language (HTML) 
format, and when the connection is closed in the above 
interaction, the server serves a passive role, i.e., it accepts 
commands from the client and cannot request the cUent to 

5 perform any action. 

The communication model under the conventional Web 
environment provides a very limited level of interaction 
between clients and servers. In many systems, increasing the 
level of interaction between components in the systems 

10 often makes the systems more robust, but increasing the 
interaction increases the complexity of the interaction and 
typically slows the rate of the interaction. Thus, the con- 
ventional Web environment provides less complex, faster 
interactions because of the Web's level of interaction 

15 between clients and servers. 

SUMMARY OF INVENTION 

A system, method and article of manufacture are provided 
for managing an environment in a development architecture 

20 framework. Service of a system is managed based on service 
level agreements and/or operations level agreements. A 
plurality of system management operations are performed. 
The system management operations include start-up and 
shut-down operations, back-up and restore operations, 

25 archiving operations, security operations, and performance 
monitoring operations. Service is planned in order to antici- 
pate and implement changes in the system. 

In an embodiment of the present invention, the planning 
of service may be carried out by service planning tools such 

30 as performance modeling tools and capacity modeling tools. 
In one embodiment of the present invention, the start-up and 
shut-down operations may be performed with the start-up 
and shut-down operations being automated. 

In one aspect of the present invention, the archiving 

■'^ operations may be performed to transfer data between 
different mediums with different compression ratios. In 
another aspect of the present invention^ the performance 
monitoring operations may be performed to determine if 
resources of the system are suf&cient to meet a desired 
performance level. 

BRIEF DESCRIPTION OF DRAWINGS 

The invention will be better understood when consider- 
ation is given to the following detailed description thereof. 
^5 Such description makes reference to the annexed drawings 
wherein: 

FIG. 1 is a schematic diagram of a hardware implemen- 
tation of one embodiment of the present invention; 

FIG. 2 is an illustration of the Integrated Development 
Environment Architecture (IDEA); 

FIG. 2a is an illustration showing a Development Orga- 
nization Framework in accordance with one embodiment of 
the present invention; 

FIG. 3 is an illustration showing a security organization 
fiinctiooal according to one embodiment of the present 
invention; 

FIG. 4 is an illustration showing the responsibilities of an 
Environmental Management Team; 
5Q FIG. 5 is an illustration showing the responsibilities of an 
Application Team structure; 

FIG 6 is an illustration showing a model migration plan 
in accordance with one embodiment of the present inven- 
tion; 

65 FIG. 7 is an illustration showing a single release capabil- 
ity development pipeline in accordance with one embodi- 
ment of the present invention; 
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FIG. 8 is an illustration showing a multiple release mous components, called objects, each of which is respon- 

capability development pipeline in accordance with one sible for a specific task. This concept of packaging data, 

embodiment of the present invention; structures, and procedures together in one component or 

FIG. 9 is an illustration showing a multiple release module is called encapsulation, 

capability development pipeline with code base synchroni- 5 [□ general, OOP components are reusable software mod- 

zation among three pipelines; ules which present an interface that conforms to an object 

FIG. 10 is all illustration showing a Development Tools model and which are accessed at run-time through a com- 

Framework in accordance with one embodiment of the ponent integration architecture. A component integration 

present invention; architecture is a set of architecture mechanisms which allow 

FIG, 11 is an illustration showing information captured in software modules in different process spaces to utilize each 

the Repository and reused; others capabilities or functions. This is generally done by 

FIG. 12 is an illustration^showing the Repository's central ^ component object model on which to 

role in the development environment; and ^^^^ architecture. It is worthwhile to differentiate 

. -.1 . u ■ ^ t * u- between an object and a class of objects at this point. An 

FIG. 13 IS an illustration showing an Operational Archi- . - * - - . - . c i c w , u- u • 

^ , . J .. . J- r object IS a single instance of the class of objects, which is 

lecture Framework in accordance w^th one embodiment of ct • * u Zi i a i r u- * u ■ ^ 

, . often just called a class. A class of objects can be viewed as 

the present mvention. ^ blueprint, from which many objects can be formed. 

DISCLOSURE OF INVENTION OOP allows the programmer to create an object that is a 

A preferred embodiment of a system in accordance with ,0 ^""^^^"^ ^""^ example, the object representing 

the present invention is preferably practiced in the context of * P^^^^ ^^5^°^ ^ ^^""^ ^ composition-relationship 

a personal computer such as an IBM compatible personal ^^h the object representmg a piston. In reahty, a piston 

computer, Apple Macintosh computer or UNIX based worit- compnses a piston, valves and many other compo- 

station. A representative hardware environment is depicted ^^^^ '^^^ ^ P^^«° ^ ^« ^^^^^^^^ of ^ P^^^" 

in FIG. 1, which illustrates a typical hardware configuration ^5 '^^^ logically and semantically represented in OOP by two 

of a workstation in accordance with a preferred embodiment objects. 

having a central processing unit 110, such as a OOP also allows creation of an object that "depends 

microprocessor, and a number of other units interconnected from" another object. If there are two objects, one repre- 

via a system bus 112. The workstation shown in FIG. I senting a piston engine and the other representing a piston 

includes a Random Access Memory (RAM) 114, Read Only 3Q engine wherein the piston is made of ceramic, then the 

Memory (ROM) 116, an I/O adapter 118 for connecting relationship between the two objects is not that of compo- 

peripheral devices such as disk storage units 120 to the bus sition. A ceramic piston engine does not make up a piston 

112, a user interface adapter 122 for connecting a keyboard engine. Rather it is merely one kind of piston engine that has 

124, a mouse 126, a speaker 128, a microphone 132, and/or one more limitation than the piston engine; its piston is made 

other user interface devices such as a touch screen (not 35 of ceramic. In this case, the object representing the ceramic 

shown) to the bus 112, communication adapter 134 for piston engine is called a derived object, and it inherits all of 

connecting the workstation to a communication network the aspects of the object representing the piston engine and 

(e.g., a data processing network) and a display adapter 136 adds further limitation or detail to it. The object representing 

for connecting the bus 112 to a display device 138. The the ceramic piston engine "depends from" the object repre- 

workstation typically has resident thereon an operating 4^ senting the piston engine. The relationship between these 

system such as the Microsoft Windows NT or Windows/95 objects is called inheritance. 

Operating System (OS), the IBM OS/2 operating system, the When the object or class representing the ceramic piston 

MAC OS, or UNIX operating system. Those skilled in the engine inherits all of the aspects of the objects representing 

art will appreciate that the present invention may also be the piston engine, it inherits the thermal characteristics of a 

implemented on platforms and operating systems other than 45 standard piston defined in the piston engine class. However, 

those mentioned. the ceramic piston engine object overrides these ceramic 

A preferred embodiment is written using JAVA, C, and the specific thermal characteristics, which are typically different 

C++ language and utilizes object oriented programming from those associated with a metal piston. It skips over the 

methodology. Object oriented programming (OOP) has original and uses new functions related to ceramic pistons. 

become increasingly used to develop complex applications. 50 Different kinds of piston engines have different 

As OOP moves toward the mainstream of software design characteristics, but may have the same underlying functions 

and development, various software solutions require adap- associated with it (e.g., how many pistons in the engine, 

tation to make use of the benefits of OOP. A need exists for ignition sequences, lubrication, etc.). To access each of these 

these principles of OOP to be applied to a messaging fiinctions in any piston engine object, a programmer would 

interface of an electronic messaging system such that a set 55 call the same functions with the same names, but each type 

of OOP classes and objects for the messaging interface can of piston engine may have different/overriding implemen- 

be provided. tations of functions behind the same name. This ability to 

OOP ts a process of developing computer software using bide different implementations of a function behind the same 

objects, including the steps of analyzing the problem, name is called polymorphism and it greatly simplifies com- 

designing the system, and constructing the program. An 60 munication among objects. 

object is a software package that contains both data and a With the concepts of composition-relationship, 

collection of related structures and procedures. Since it encapsulation, inheritance and polymorphism, an object can 

contains both data and a collection of structures and represent just about anything in the real world. In fact, our 

procedures, it can be visualized as a seff-sufficient compo- logical perception of the reality is the only limit on deter- 

nent that does not require other additional structures, pro- 65 mining the kinds of things that can become objects in 

cedures or data to perform its specific task. OOP, therefore, object-oriented software. Some typical categories are as 

views a computer program as a collection of largely autono- follows: 
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Objects can represent physical objects, such as automo- 
biles in a traflSc-flow simulation, electrical components 
in a circuit-design program, countries in an economics 
model, or aircraft in an air-trafiEc-control system. 

Objects can represent elements of the computer-user 5 
environment such as windows, menus or graphics 
objects. 

An object can represent an inventory, such as a personnel 
file or a table of the latitudes and longitudes of cities. 

An object can represent user-defined data types such as 10 
time, angles, and complex numbers, or points on the 
plane. 

With this enormous capability of an object to represent 
just about any logically separable matters, OOP allows the 
software developer to design and implenaent a computer 
program that is a model of some aspects of reality, whether 
that reality is a physical entity, a process, a system, or a 
composition of matter. Since the object can represent 
anything, the software developer can create an object which 
can be used as a component in a larger software project in 20 
the future. 

If 90% of a new OOP software program consists of 
proven, existing components made from preexisting reus- 
able objects, then only the remaining 10% of the new 
software project has to be written and tested from scratch. ^5 
Since 90% already came from an inventory of extensively 
tested reusable objects, the potential domain from which an 
error could originate is 10% of the program. As a result, 
OOP enables software developers to build objects out of 
other, previously built objects. 3Q 

This process closely resembles complex machinery being 
built out of assemblies and sub-assemblies. OOP 
technology, therefore, makes software engineering more like 
hardware engineering in that software is built from existing 
components, which are available to the developer as objects. 35 
All this adds up to an improved quality of the software as 
well as an increased speed of its development. 

Programming languages are beginning to fully support the 
OOP principles, such as encapsulation, inheritance, 
polymorphism, and composition-relationship. With the ^ 
advent of the C++ language, many commercial software 
developers have embraced OOP C++ is an OOP language 
that offers a fast, machine -executable code. Furthermore, 
C++ is suitable for both commercial-application and 
systems-programming projects. For now, C++ appears to be ^5 
the most popular choice among many OOP programmers, 
but there is a host of other OOP languages, such as 
Smalltalk, Common Lisp Object System (CLOS), and Eiffel, 
Additionally, OOP capabilities are being added to more 
traditional popular computer programming languages such jq 
as Pascal. 

The benefits of object classes can be summarized, as 
follows: 

Objects and their corresponding classes break down com- 
plex programming problems into many smaller, sim- 55 
pier problems. 

Encapsulation enforces data abstraction through the orga- 
nization of data into small, independent objects that can 
communicate with each other. Encapsulation protects 
the data in an objea fi-om accidental damage, but 60 
allows other objects to interact with that data by calling 
the object's member functions and structures. 

Subclassing and inheritance make it possible to extend 
and modify objects through deriving new kinds of 
objects from the standard classes available in the sys- 65 
tem. Thus, new capabilities are created without having 
to start from scratch. 



Polymorphism and multiple inheritance make it possible 
for different programmers to mix and match character- 
istics of many different classes and create specialized 
objects that can still work with related objects in 
predictable ways. 
Class hierarchies and containment hierarchies provide a 
flexible mechanism for modeling real-world objects 
and the relationships among them. 
Libraries of reusable classes are useful in many situations, 

but they^ also have some limitations. For example: 
Complexity, in a complex system, the class hierarchies for 
related classes can become extremely confusing, with 
many dozens or even hundreds of classes. 
Flow of control. A program written with the aid of class 
libraries is still responsible for the flow of control (i.e., 
it must control the interactions among all the objects 
created from a particular library). The programmer has 
to decide which functions to call at what times for 
which kinds of objects. 
Duplication of effort. Although class libraries allow pro- 
grammers to use and reuse many small pieces of code, 
each programmer puts those pieces together in a dif- 
ferent way. Two different programmers can use the 
same set of class libraries to write two programs that do 
exactly the same thing but whose internal structure 
(i.e., design) may be quite different, depending on 
hundreds of smaU decisions each programmer makes 
along the way. Inevitably, similar pieces of code end up 
doing similar things in slightly different ways and do 
not work as well together as they should. 
Class libraries are very flexible. As programs grow more 
complex, more programmers are forced to reinvent basic 
solutions to basic problems over and over again, A relatively 
new extension of the class library concept is to have a 
framework of class libraries. This framework is more com- 
plex and consists of significant collections of collaborating 
classes that capture both the small scale patterns and major 
mechanisms that implement the common requirements and 
deign in a specific application domain. They were first 
developed to free application programmers from the chores 
involved in displaying menus, windows, dialog boxes, and 
other standard user interface elements for personal comput- 
ers. 

Frameworks also represent a change in the way program- 
mers think about the interaction between the code they write 
and code written by others. In the early days of procedural 
programming, the programmer caUed libraries provided by 
the operating system to perform certain tasks, but basically 
the program executed down the page from start to finish, and 
the programmer was solely responsible for the flow of 
control. This was appropriate for printing out paychecks, 
calculating a mathematical table, or solving other problems 
with a program that executed in just one way. 

The development of graphical user interfaces began to 
turn this procedural programming arrangement inside out. 
These interfaces allow the user, rather than program logic, to 
drive the program and decide when certain actions should be 
performed. Today, most personal computer software accom- 
plishes this by means of an event loop which monitors the 
mouse, keyboard, and other sources of external events and 
calls the appropriate parts of the programmer's code accord- 
ing to actions that the user performs. The programmer no 
longer determines the order in which events occur. Instead, 
a program is divided into separate pieces that are caUed at 
unpredictable times and in an unpredictable order. By relin- 
quishing control in this way to users, the developer creates 
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a program that is much easier to use. Nevertheless, indi- frameworks, they reuse design. A framework embodies 

vidual pieces of the program written by the developer still the way a family of related programs or pieces of 

call b'braries provided by the operating system to accomplish software work. It represents a generic design solution 

certain tasks, and the programmer must still determine the that can be adapted to a variety of specific problems in 

flow of control within each piece after it*s called by the 5 a given domain. For example, a single framework can 

event loop. AppUcation code still "sits on top of* the system. embody the way a user interface works, even though 

Even event loop programs require programmers to write ^wo different user interfaces created with the same 

a lot of code that should not need to be written separately for framework might solve quite different interface prob- 

every apphcation. The concept of an application framework ^^^^ 

carries the event loop concept further. Instead of dealing ,„Tn.*L , e e ic 1 

„ , J u 1. c * *• u ' 10 Thus, through the development of frameworks for solu- 
with all the nuts and bolts of constructing basic menus, . . . .1 ^ .1 
windows, and dialog boxes and then making these things all to various probletns and programming tasks sign^- 
work together, programmers using application frameworks reductions m the design and development effort for 
start with working application code and basic user interface software can be achieved. A preferred embodiment of the 
elements in place. SubsequenUy, they build from there by ^nvention utilizes HyperText Markiip Unguage (HTML) to 
replacing some of the generic capabilities of the framework implement documents on the Internet together with a 
with the specific capabilities of the intended application. general-purpose secure communication protocol for a trans- 
Application frameworks reduce the total amount of code port medium between the client and the Newco. HTTP or 
that a programmer has to write from scratch. However, other protocols could be readily substituted for HTML 
because the framework is really a generic application that without undue experimentation. Information on these prod- 
displays windows, supports copy and paste, and so on, the 20 ucts is available in T. Bemers-Lee, D. Connoly, "RFC 1866: 
programmer can also relinquish control to a greater degree Hypertext Markup Language — 2.0" (November 1995); and 
than event loop programs permit. The framework code takes R. Fielding, H, Frystyk, T Bemers-Lee, J. Gettys and J. C, 
carcof almost all event handling and flow of control, and the Mogul, "Hypertext Transfer Protocol — HTTP/Ll: HTTP 
programmer's code is caUed only when the framework Working Group Internet Draft" (May 2, 1996). HTML is a 
needs it (e.g., to create or manipulate a proprietary data ^5 simple data format used to create hypertext documents that 
structure). portable from one platform to another. HTML docu- 
A programmer wntmg a framework program not only ^^^^^ g^j^L documents with generic semantics that are 
relmquishes control to the user (as is also true for event loop appropriate for representing information from a wide range 
programs), but also rehnquishes the detailed flow of control domains, HTML has been in use by the World-Wide Web 
within the program to the framework. This approach allows ^^^^^y information initiative since 1990. HTML is an appli- 
the creation of more complex systems that work together in nation of ISO Standard 8879; 1986 Information Processing 
interesting ways, as opposed to isolated programs, having xg^t and OflBce Systems; Standard GeneraUzed Markup 
custom code, being created over and over again for similar Language (SGML). 

problems. ^^j^^ y^^^ development tools have been limited in their 

Thus, as is explained above, a framework basically is a 35 ^biUty to create dynamic Web applications which span from 

collection of cooperating classes that make up a reusable ^li^nt to server and interoperate with existing computing 

design solution for a given problem domam. It typicaUy ^sources. Until recently, HTML has been the dominant 

mcludes objects that provide default behavior (e.g., for technology used in development of Web-based solutions. 

menus and windows), and programmers use it by inheriting However, HTML has proven to be inadequate in the fol- 

some of that default behavior and overriding other behavior lowing areas: 

so that the framework calls application code at the appro- „ _c 

• ^. Poor performance; 
pnate times. 

There are three main differences between frameworks and Restncted user interface capabQities; 

class libraries: only produce static Web pages; 

Behavior versus protocol. Class libraries are essentiaUy 45 Lack of interoperability with existing applications and 

collections of behaviors that you can call when you data; and 

want those individual behaviors in your program. A Inability to scale. 

framework, on the other hand, provides not only behav- Sun Microsystem's Java language solves many of the 

ior but also the protocol or set of rules that govern the client-side problems by: 

ways in which behaviors can be combined, including 50 Improving performance on the client side; 

rules for what a programmer is supposed to provide Enabling the creation of dynamic, real-time Web appli- 

versus what the framework provides. cations; and 

Call versus override. With a class library, the code the Providing the ability to create a wide variety of user 

programmer instantiates objects and calls their member interface components. 

functions. It's possible to instantiate and call objects in 55 With Java, developers can create robust User Interface 
the same way with a framework (i.e., to treat the (UI) components. Custom "widgets" (e.g., real-time stock 
framework as a class Ubrary), but to take fuU advantage tickers, animated icons, etc.) can be created, and client-side 
of a framework^s reusable design, a programmer typi- performance is improved. Unhke HTML, Java supports the 
cally writes code that overrides and is called by the notion of client-side vahdation, offloading appropriate pro- 
framework. The framework manages the flow of con- 50 cessing onto the client for improved performance. Dynamic, 
trol among its objects. Writing a program involves real-time Web pages can be created. Using the above- 
dividing responsibilities among the various pieces of mentioned custom UI components, dynamic Web pages can 
software that are called by the framework rather than also be created. Sun's® Java® language has emerged as an 
specifying how the different pieces should work industry-recognized language for "programming the Inter- 
together. 65 net." Sun defines Java as: "a simple, object-oriented. 
Implementation versus design. With class libraries, pro- distributed, interpreted, robust, secure, architecture-neutral, 
grammers reuse only implementations, whereas with portable, high-performance, multithreaded, dynamic. 
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buzzword-compliant, general-purpose prograxnming Ian- While it seenas intuitive thai most tasks can be 

guage. Java supports programming for the Internet in the streamlined, the following list gives a few examples of 

form of platform-independent Java applets." Java applets are redundant tasks that must be eliminated: 

small, specialized applications that comply with Sun's Java Analysis to determine how to merge the uncoordinated 

Application Programming Interface (API) aUowing devel- 5 changes applied by two programmer to the same 

Offers to add "interactive content" to Web documents (e.g., module 

simple animations, page adornments, basic games, etc.). ^ . c j j**- r ji 

^ \ T L / Re-entry of the source code and retestmg of a module. 

Applets execute withm a Java-compatible browser (e.g., , - / ,j * n j 1 * ^ 

. / ^ . . . \o» which was accidentally deleted 

Netscape Navigator) by copying code from the server to _ - , . 1 • 1111 

cUent. From a language standpoint, Java's core feature set is 10 R^^^nng discussions about what a design packet shou d 

based on C++. Sun^s Java literature states that Java is or what constitutes good programming style 

basically, "C++ with extensions from Objective C for more ^ ^ particular context 

dynamic method resolution." Repeated design, coding, teslmg, and maintenance of very 

Another technology that provides simUar function to similar logic (for example, error handling, date con- 

JAVA is provided by Microsoft and ActiveX Technologies, 15 ^^^^^o mampulation, main structure of a module) 

to give developers and Web designers wherewithal to build Searching for the manuals of a particular productivity tool 

dynamic content for the Internet and personal computers. *o find information 

ActiveX includes tools for developing animation, 3-D vir- Remigration to system test of a cycle, because the impact 

tual reality, video and other multimedia content. The tools analysis for a change request was incomplete 

use Internet standards, work on multiple platforms, and are 20 Requesting support from another team (for example, 

being supported by over 100 companies. The group's build- environment support, information management) and 

ing blocks are called ActiveX Controls, small, fast compo- waiting unnecessarily for a response 

nents that enable developers to embed parts of software in On a smaller project, these problems can be solved using 

hypertext markup language (HTML) pages. ActiveX Con- a brute force approach. This becomes very expensive as the 

trols work with a variety of programming languages includ- 25 project grows, and finally impossible. A well-designed 

ing Microsoft Visual C++, Borland Delphi®, Microsoft development environment becomes important as the project 

Visual Basic® programming system and, in the future, team reaches 20-SO people and is absolutely critical with a 

Microsoft's development tool for Java, code named project size of more than 50 people. 

"Jakarta®." ActiveX Technologies also includes ActiveX The investment required to design, set up, and tune a 

Server Framework, allowing developers to create server 30 comprehensive, good development and maintenance, envi- 

applications. One of ordinary skill in the art readily recog- ronment is typically several hundred development days. 

nizes that ActiveX could be substituted for JAVA without Numbers between 400 and 800 days are commonly seen, 

undue experimentation to practice the invention. depending on the platforms, target environment complexity. 

Development Framework (IDEA) amount of reuse, and size of the system being developed and 

FIG. 2 is an illustration of the Integrated Development 35 maintained. 

Environment Architecture (IDEA). The Integrated Develop- Development Organization Framework 

ment Environment Architecture provides a development FIG. 2a is an illustration showing a Development Otga- 

environment framework and associated guidelines that nization Framework in accordance with one embodiment of 

reduce the effort and costs involved with designing, the present invention. When designing a business 

implementing, and maintaining an integrated development 4^ application, it is crucial to keep in mind the organization that 

environment. IDEA takes a holistic approach to the devel- will use the system. The same is true of the development 

opment environment by addressing all three Business Inte- environment. The development organization's size, 

gration components: organization, processes, and tools. structure, experience, and maturity should strongly influence 

The development environment is a production environ- the choice of tools and the way the tools are integrated. If 
ment for one or several systems development projects as 45 this link is not understood, the benefit of tool support will be 
well as for maintenance efiforts. It requires the same attention minimal in many areas, and may significantly reduce pro- 
as a similarly sized end-user execution environment. duciivity. 

The purpose of the development environment is to sup- In the same way, when a new business capability is 

port the tasks involved in the analysis, design, construction, inU-oduced, it is crucial to keep in mind the needs for training 

and maintenance of business systems, as well as the asso- 50 and organizational change that which may accompany the 

ciated management processes. The environment should technical change. This ts also true of the development 

adequately support all the development tasks, not just the environment. When a new development environment is put 

code/compile/test/debug cycle. Given this, a comprehensive in place, the developers need to learn not only how each 

framework for understanding the requirements of the devel- individual tool works (for example, how to use the 

opment environment should be used. 55 compiler), but also how the tools work together to support 

Another reason for the comprehensive framework is that the organization as it performs well defined processes, 

it is important to get the development environment right the The Business Integration Methodology (BIM) provides 

first time. Changing the development environment when valuable information on organizational issues. 

consUiiction is fully staffed entails serious disruptions and Relying on the Business Integration Methodology and its 

expensive loss of productivity. project organization guidelines (0940 — Organize Project 

Experience has shown that within the same medium- to Resource Task Package), the following should be prepared: 

large-size project, with the same people, moving from a poor A list of responsibilities covering both responsibilities for 

to a good development environment, productivity is end products and those for on-going processes 

improved by a factor of ten for many tasks. The improve- a Responsibility, Accountability, and Authority profiles 

ments come in two categories: 55 deliverable (RAA) for each role in the Development 

The elimination of redundant and non value-added tasks team, making sure that all the responsibilities listed 

The streamhning of useful tasks earlier are covered 
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The RAA profiles deliverable consists of slatemcDts about capable of holding all the information resources of a project, 

the responsibilities, accountability, and authority of each of It is, for example, common to have key project information 

the positions in the development organization. These state- reside in a combination of repositories, teamware databases, 

meats define the role of each position in terms of: flat files, and paper documents. It is the Information Mao- 
Responsibility— What objectives the position is expected 5 agement team's responsibility to ensure consistency across 

to accomplish these formats. The responsibilities of the Information 

. . TT J u L _r 11 Management team therefore cover: 

Accountability — How and by whom the performance will ^ . 

be measured Repository Management 

Authority — ^The position's decision-making capabilities ^^l^^'^ Management 

and limits Object Managemem 

In accordance with the IDEA Model, the following man- ^edia Content Management 

agement teams with responsibilities for the key management Information and data reuse coordination 

functions are defined as: addition to managing the information for the System 
The iDformation Management team 262 15 ^""^'"S learn tht Inforaiation Management team must also 

^ ^ ^ manage the iniormation resources or the other management 

The Quality team 264 ^ r, , • , ^ , 

' processes — quauty management, environment management. 

The Environment Management team 266 and project management. 

The Release Management team 268 In order to delineate the responsibilities of the Informa- 

The Configuration Management team 270 tion Management team, it is useful to state those areas that 

The Problem Management team 272 ^re out of scope. The foUowing are not included: 

The Program and Project Management teams 274 Performance of daily backups— this is handled by the 

The Security Management team 276 Environment Management team 

Together, these teams support the efforts of the System Database admmistration-this is part of the Architecture 

BuUding team, which is charged with the analysis, design, 25 responsibiHties 

build, and test of the system to be developed. These teams Performance tuning of the mformation repositones— this 

represent real roles, and on a given program the same people ^ handled by Environment Management 

may play different roles. Repository Management 

Security Management Information Management team is ultimately respon- 

The evolution of new technologies and expanded access 30 ^^^^ contents of the repository. They need to have an 

to a virtual world has increased the security risk of conduct- intimate understanding of the repository structure and the 

ing business. It is therefore essential to recognize the need that govern how different objects should be stored in 

for a new unit in the organization, specifically dedicated to repository. 

ensuring that security is handled appropriately. At the Pro- Although most of the input to the repository are entered 
gram level, the Security Management unit needs to: 35 designers, the Repository Management team must man- 
Ensure all security issues are effectively addressed ^Sf this population process. Rather than taking a policing 
throughout the program (aU business and IT processes). °° P^°J^^ '^^y ^^'""^^ f facihtators-helping 
c , . 11 J tbc designers do things correctly the first time, thereby 
Act as facihtator and approvme body for all new and ■ * • - ,u - * % t *u \xr.u \ . 

^ r ^ . mamtammg the integnty of the repository. Without strong 

existing initiatives that contain security components. / *u u c* c * 

^ 40 repository management, the benefits of using a repository 

Own responsibility for the organization and facilitation of quickly diminish 

working groups that would address security issues. i„ ^^^^y situations the Information Management team 

Be responsible for development and maintenance of the must make decisions that affect functional areas. To 

Security Plan. empower the Information Management team, the Applica- 

FIG. 3 is an illustration showing a security organization don teams should include the Information Management 

according to one embodiment of the present invention. A team in relevant design discussions. This facilitates the 

Security Management Team may have a security manage- validation of design outputs, 

ment 300, under which are an administration team 302, a Folder Management 

projects & planning team 304, and a business process Folders (or directories) can be very useful in gaining 
security team 306. The size of the Security Management control over the ovcrwhehning amount of information pro- 
team, and the way in which it is integrated into the devel- duced on a large project. Their utility greatly increases if 
opment organization depends on the degree to which secu- they are managed appropriately. This management is based 
rity is a factor for each specific environment. For example, on easy-to-follow, easy-to-enforce standards, 
the security risks associated with an Intcraet-based online Object Management 

banking system arc far greater than those of a fully isolated The responsibiHties involved with object management are 

client/server system, and therefore warrant a larger team very similar to those involved with repository management, 

with broader responsibilities and greater influence. However, in order to facilitate and promote reuse, it is 

Information Management recommended to have a librarian whose responsibilities 

The Information Management team is responsible for include: 

ensuring that the project's knowledge capital and informa- Reviewing designs 

tion resources are managed effectively. This includes: Packaging classes and components for reuse 

Ensuring mtegnty Managing maintenance and upgrades of common corn- 
Ensuring accessibility ponents (a strong relationship with Configuration Man- 
Ensuring quality and consistency agement team is required) 
Information Management encompasses Repository 65 Media Content Management 
management, but generally has a broader scope than merely The methods of handling media content are somewhat 
the repository contents, because most repositories are not different from those surrounding more traditional develop- 
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meat conieoi such as code or documentation, for this reason. To lest proof of concept 

a role should be defined that is responsible for the manage- Xo reduce risk 

ment of all media content. The Release Management team is responsible for: 

Quality Management Planning the capabiHty release design and development 

The QuaUty team is responsible for dcfinmg and imple- 5 ^q^^^ ^^^cd on the capabihty development approach 

menting the Quality Management Approach, which means timeline 

defining what Quality means for the Program Leadership, Measuring and monitoring progress using cstabUshed 

and then implementing the procedures, standards, and tools processes to ensure that a capability release is delivered 

requued to ensure the delivery of a quality program. The ^„ ^^^^ ^^^^^ budget, and that it meets or exceeds 

Quality Management Approach addresses concepts such as lo ^™«^*^ti^«o 

. expeciaiions. 

expectation management, quality verification, process am ■ -.-.j ^ - . ji- r 

. J • 5 Managing project mterdependencies to ensure dehvery 01 

management, metrics, and contmuous improvement. the ca abilit release 

Since quality is the result of the interaction of many teams . , 

working on multiple processes, the Quality team is respon- Ensuring that resources are used effectively across 

sible for ensuring effective cooperation between teams and 15 projects for the release. 

good integration of the development processes. The Quality As wnh many other management responsibilities 

team must therefore forge strong links with all the other described m IDEA, Release Management is more a role than 

project teams ^ function. It is good practice to have as many areas as 

It IS important to note that the QuaUty team is not only P^^^^^ represented in the Release Management team; for 

responsible for ensuring the quality of the system buHding 20 ^'^^P*^' ^^^^^^n. Construction, Configuration, and Environ- 

process. The Quality team is also directly involved in ment Management team members would make up a typical 

ensuring the quaUty of the other IDEA management pro- ^^^^"^ Management team, each providing input based on 

(.ggg^g their own perspective. 

Program & Project Management Environment Management 

The Program Management team is responsible for deliv- 25 ^^^^ ^. ^"^"^^^ application requires support and system 

cring business capability. In this respect, it is responsible for ^^^^^^ ^^^J devcbpment environment requues 

the System Building and other management teams. In ^y^^^*" operations daily and developers require ongoing 

addition, other management responsibilities that do not have ^^"PP^^^ ^'^^^ environment effectively (In fact, 

a specific team or role defined within IDEA also belong to complexity and frequence of these operations is often 

the Program Management team. These include: 30 ^^^"^ ""[^^^ execution environment). 

P . ^ To ensure that thife area receives the necessary attention, 

^ y ^ an Environment Management team 400 should be assigned 

Financial Management ^^^^ PIG 4 illustration showing the Enviroo- 

Issue Management (decisions to be made regarding the mental Management Team responsibilities, 

development of the business capabUity, not to be con- jhe Service Group 402 serves as a single point of contact 

fused with problem management) for developers. It interfaces with the Architecture team to 

Program Performance Reporting provide answers to questions from developers. To avoid 

Resource Management adding overhead to the issue resolution process, the support 

Risk Management group must be staffed adequately to ensure that all questions 

Vendor Management 40 answered. For example, the support group should recruit 

Tlie Project Management team is responsible for produc- P^^P^f ^^"^/^^ Technology Infrastructure team at the 

ing a dehverable or set of deliverables. As such, it is completion of Technology Infrastructure development, 

responsible for: ^'""^^^^ Management , . _ 

J If.,- Problem Management is concerned with the discrepancies 

Plannmg and control of dehvery . ^^^^^^ p^^^ management of 

Milestones and schedule design problems detected during verification or validation 

Resource consumption steps throughout the development process. 

Risk and quality (at dehverable level) The Problem Management team is responsible for defin- 

Configuration Management ing the problem tracking and solution process, and for 

The Configuration Management team is responsible for providing tools and procedures to support the solution 

defining the approach the program takes to deal with scope, process, 

change control, version control, and migration control, and System Building 

for putting in place the policies, processes, and procedures The Business Integration Methodology (BIM) describes 

required to implement this approach. System Building under the following activities: 

In other words, the team is responsible for maintaining the Design application 

integrity of software and critical documents as they evolve Build and test application 

through the dehvery fife cycle from analysis through deploy- ^^^^^^ technology infrastructure 

Build and test technology infrastructure 

Release Management , ^ ^ ^ For this reason, the System Building teams are organized 

Deliverine a system on a release-based approach means ^„ - , ,- » ^ * u 1 i c . ^ 

. . ^ - , 60 mto application and technology Infrastructure, 

delivering the system in a senes of consecutive releases, ApDlication Team 

increasing or refining frinctionaliiy progressively. Some of m, a i- *• . caa ■ * r 

. . .. ^. .1. Ine Application team 500 consists of three separate 

the main drivers to such an approach mclude: ^..k«^ ^ a r a us . cnt a r A 1 

^'^ subteams; Application Architecture 502, Apphcation Devel- 

To release business benefits early ^^^^^^ Sy^t^^, y^st PIG 5 3„ illustration 

To mitigate impact on the organization 55 showing the Apphcation Team structure and responsibihties. 

To keep the cliange program up to date The structure of the Application team evolves as the 

To optimize processes development process continues — as the development of the 
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application arphiiecture components is completed, the 
Application Architecture team's roles may change. While 
the team continues maintaining the application architecture 
components, some team members may be deployed to the 
Application Development team. Here their roles can include 
helping application developers to correctly use the architec- 
ture components, providing development support, and per- 
forming code reviews, and so forth. 

As systems become more user-facing, important new 
roles are emerging that must be integrated into the Appli- 
cation Development teams: 

a) Media Content Design 

For any system with a user-facing component, it is 
extremely iinportant that media and design specialists are 
involved as team members at an early stage in the design of 
the system. In systems with simple user interfaces, this helps 
to ensure usability and consistency. As user interfaces 
become more complex, the early involvement of design 
experts not only leads to more creative and attractive user 
interfaces, but also reduces the risk of further alteration to 
work at a later stage. 

b) Usability 

Often coupled with Media Content Design, it is vital that 
a role for usability is defined within the Application Devel- 
opment teams. This will ensure the usability of the system 
from the perspective of target user groups. 
Technology Infrastructure Team 

The technology infrastructure evolves throughout the 
project and responsibility for managing and evolving the 
infrastructure must be clearly defined. Therefore, rather than 
having a single amorphous * technical team' (responsible for 
operations, support, architecture evolution, and more), it is 
important to define a dedicated technology infrastructure 
team. By allowing the technology infrastructure team to 
focus on the technology infrastructure, rather than the day to 
day running of the environment, the project increases the 
chances that the technology infrastructure will provide good 
support for the business applications. 

In practice, the Technology Infrastructure team is the team 
that will implement the IDEA framework. 

The Technology Infrastructure team is responsible for: 

Data design and management 

Database administration 

Database tuning 

Execution architectiu-e design and construction 
Development architecture design and construction 
Operations architecture design and construction 
Network design 

Technical standards design and documentation 

System software selection 

Performance tuning of the final system 

Security infrastructure development 
Note: The responsibilities of the Technology Infrastructure 
team may overlap with those of the Application Architecture 
team, and on some projects the two teams are often com- 
bined: 

Development Processes Framework 

A thorough understanding of the development processes 
is a prerequisite for ensuring that the tools effectively 
support the organization and the processes they are intended 
to support. 

The Development Process Model 

The Development Process Model is a framework that 
facilitates the analysis of the many concurrent processes of 
systems development. This analysis helps understand pro- 
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cess interaction, which, in turn, affects organizational inter- 
action and defines a need for tools integration. 

The Process model is simple — at its core is the system 
building process, which is surrounded by eight key man- 
5 agement processes. 

The core activity — systems building, depends strongly on 
support from the surrounding management processes, which 
ail affect each other: 

a) Information Management manages the information that 
supports the entire project— information that is used 
both in systems, building and in other management 
processes 

b) Security Management covers all areas of development 
security, from coding standards, to security verification. 

c) Quality Management pertains to all areas of the devel- 
opment environment 

d) Program and Project Management must manage all the 
management processes in addition to managing the 

20 systems building process 

e) Environment Management supports the environment 
where management processes are performed, and 
where systems are being built 

f) Release Management manages the simultaneous devel- 
25 opment of multiple releases 

g) Configuration Management, often closely linked with 
release management covers the version control, migra- 
tion control and change control of system components 
such as code and its associated documentation 

h) Problem Management pertains to the problem tracking 
and solution process 

Process Definition 

For a given project, each of the processes must be defined 
at a greater level of detail than that which any methodology 
can achieve. This additional specification consists of a set of 
procedures and standards that specify how to perform the 
work and what to produce at each step. 

Standards specify what the results should look like. They 
^ may include industry standards and more formal (de jure) 
standards, such as POSIX compliance, but most standards 
are project specific and determine, for example, how to 
structure and name system components and where to place 
system components. Standards make it possible for a large 
team to exchange information effectively and to work pro- 
ductively together. 

Standards should focus on what must be common, and 
should not become a goal in themselves. Erring on the side 
of over-standardization stifles productivity. It is, however, 
often the case that unforeseen events (such as platform 
demise, tool evolution) will be easier to tackle the more 
unified the development approach has been used. 
Unfortimately, there is no substitute for experience when 
making the detailed decisions on exactly what should be 
standardized. Factors to take into account must at least 
include: 

Life expectancy of the system under development — the 
higher the life expectancy, the more standards are 
warranted 

50 Life expectancy of the development organization — the 
higher the life expectancy, the more standards are 
justified 

Attrition — a stable organization can tackle more detailed 
standards than a volatile one 
65 Expected change in the environment — a high rate of change 
provides greater opportunity to reap the benefits of a stan- 
dardized approach 
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Procedures specify how to perform a task. They are 
generally guided by the methodology but provide informa- 
tion at a lower level of detail. They are highly environment- 
specific, and take into account the organization, the 
standards, and the tools in the environment. EVocedures 
often specify the techniques to be used. They may specify 
which tools to use and how to use the tools thai support these 
techniques. 

Many processes require individual judgment, and the way 
to perform these processes cannot be specified in detail. In 
such cases, it may be valuable to provide guidelines that do 
not have the mandatory flavor of procedures but rather that 
of valuable advice. 

While it is easy to generate zeal to set up standards and 
procedures at the beginning of a project, it can sometimes be 
more difiBcult to ensure that these arc enforced throughout 
the project. Two considerations are usefiiL Firstly, standards 
must be easy to follow. It should be easier to follow the 
standard than doing things any other way. This is generally 
achieved by supplying the training, tools, and support 
needed to facilitate a given work style. For example, devel- 
oping and distributing application program shells, which 
respect the architecture and standards, facilitates program- 
ming and contributes to ensuring broad standards compli- 
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level. Tools that support processes performed by different 
individuals may only have to be integrated at the data level. 

See Tools — Process Management for more details. 
Security Management 

Processes must be put into place in order to ensure 
security is properly designed and built into the system that 
is being developed, including: 

Definition of security requirements based on business risk 

Development of security standards, guidelines and pro- 
cedures 

Implementation of security controls 

Security validation 
Security Requirement Definition 

Security requirements are the outcome of the security 
Risk Assessment. This is the process of identifying business 
risks, identifying system vulnerabilities or weaknesses that 
can impact those risks, and recommending mechanisms to 
control the vulnerabdities. Specific confidentiality, integrity 
and availability requirements for the new system and the 
development environment are defined through this process. 
Security Standards, Guidelines and Procedures 

Security standards, guidelines and procedures provide 
security direction to the implementation. They will help 



ance. Secondly, the responsibility for enforcing standards 25 define how the security requirements developed through the 

must be clcariy identified and assigned. Standards enforce- Risk Assessment must be addressed in all areas of the 

ment must take place as a natural part of the process and at development environment. They will include security stan- 

well-defined check points before work flows to the next task, c^ards for the development environment infrastructure, pro- 

or (even more importantly) to the next group or team. cedures for the development processes, standards for the 

Avery useful way of complementing the specification of 30 design of the security architecture and security guidelines 
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procedures is to provide samples. Samples can sometimes 
convey a message much faster than pages of explanatory 
prose. Sample programs are generally very useful. Other 
samples may include logs, which demonstrate interaction 
with tools, a sample change request, or a sample request for 
technical support. Samples can sometimes be created efiB- 
ciently by taking screen dumps. This can be much faster than 
specifying what the screen should look like in theory. 

Samples and standards must be high quahty — any quality 
breach will be multiplied when developers start using them. 
It is therefore imperative that samples and standards not be 
created in a vacuum but be based on concrete experience 
with the project's development environment. Some pilot 
development work often proves extremely useful when fine 
tuning the standards. 

When documenting the process, it is useful to develop an 
approach and process description for each project segment 
and for each high-level process. This document summarizes 
the support available for that segment or process. It refers to 
aU the standards, procedures, guidelines, and examples 
relevant to a collection of ta^. Such a summary document 
makes it easier for developers to navigate the standards and 
hence to follow them. 
Process Integration 

To ensure that the project team works effectively together, 55 
numerous processes must be integrated. A simple example is 
provided by the required integration between design and 
construction. A more subtle one is ihe integration of product 
quality inspection and the continuous improvement process. 

As process integration frequently involves several teams, 60 
it is crucial to understand the interfaces between processes 
and teams to ensure good hand-oflk. This understanding 
must have a direct impact on tools integration, so that 
integrated processes are supported by integrated tools. Tools 
that support multiple processes performed by the same 55 
individual must, at a minimum, be integrated at the user 
interface level and should ideally be integrated at the process 



for programming. It is especially important to ensure the 
security of the development environment because if these 
systems are broken into and back doors are introduced, it 
may lead to later compromise of the production system. It 
will be the responsibility of all developers that these seciirity 
controls are implemented and adhered to throughout the 
development process. 
Security Validation 

In order to ensure the security of the system, periodical 
40 security audits should be arranged, in order to verify that the 
processes and architecture and application components that 
arc being developed conform to security proven practices. 
This may be done by an external body specializing in 
security (such as Global TIS — Security) in the form of 
45 interviews, architecture and code reviews, and automated 
tool assessment. 
Information Management (262) 

A vast amount of information is generated within the 
development environment, which needs to be carefuUy 
50 managed (for example, design documentation, application 
code, media content, test plans and test data). Information 
Management generaUy involves Repository Management, 
Folder Management and, where applicable. Object Manage- 
ment and Media Content Management. Since a number of 
55 teams rely on the service provided by the information 
management team, it is important that the level of service to 
be provided be chosen carefully, documented, and commu- 
nicated. The arrangement should take the form of a Service 
Level Agreement (SLA). Such an SLA typically defines how 
quickly a new data element is created and how repository 
changes are communicated. More generally it defines the 
division of responsibilities between the information man- 
agement team and the other project teams at a detailed level. 
Repository Management (202) 

Repository Management includes activities such as: 
Monitoring and controlling update activities in the reposi- 
tory 
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Receiving and validating data element change requests 
Creating and modifying data elements 
Enforcing project standards regarding repository objects 
Validating the contents of the repository to avoid redun- ^ 

dancy and inconsistencies 
Ensuring accuracy of the repository contents so that the 

repository reflects the applications being developed 
Importing and exporting from one repository to another 
Maintenance of the information model (or metamodel), lo 

which describes how data is represented within the 

repository 

As many repositories do not provide sufficient versioning 
functionality, it is common to have more than one repository 
on large projects. Typically, there may be one repository for 15 
development, one for system test, and one for production. 
This allows better control, but also requires significant 
resources to move repository objects from the development 
environment to the system test environment. By merging the 
development and system test repositories, the medium-sized 20 
project has a potential for productivity gains. If these gains 
are to be realized, great care must be taken when making 
corrections during system test. As a common repository is 
shared, any error analysis involving repository objects must 
take into account the possibility thai these objects could 25 
have changed since the previous migration to system test. 
This situation can be managed by meticulously maintaining 
a comprehensive change log. 

Another reason for maintaining several copies of the 
repository is the existence of concurrent projects focusing on 30 
different releases. If this is the case, it may be beneficial to 
maintain delta repositories, which document those compo- 
nents that have been modified. This requires strict repository 
management but the reward can be significant. It allows the 
merging of several releases, which have implemented 35 
complementary functionality, but which have modified a 
few shared components. 

A single development environment may have to deal with 
multiple repositories; 

For functional reasons, one repository might be integrated ^ 
with an upper-case design tool and the other with a 
lower-case generation tool 

In a multi-site environment, repositories may be distrib- 
uted over different locations. In order to keep these 
repositories synchronized, well defined development 
processes must be implemented. 

Repository Management can be divided into the following 
areas: 

Security 

Maintenance 

Validation and mass change 
Analysis, reporting, and querying 
Security 

Restricted access to various repository object types is 55 
necessary to ensure high quality repository content, because 
developers sometimes take shortcuts and make unauthorized 
changes to meet their deadlines. When standards have been 
set, a good way to enforce them is to restrict personnel 
through the use of locking mechanisms. Access to repository 60 
object types will change throughout the project. 

The data elements should usually be controlled by the 
Repository Management team, because they are the basic 
building blocks of the system and have broad reuse. Poorly 
defined data elements can cause inconsistency, redundancy, 65 
and generation errors. Data elements should therefore be 
locked at least by the time construction starts, and possibly 



,573 Bl 

20 

earlier, depending on the discipline of the team. Project 
members must be allowed to browse the data elements, but 
only the Repository Management team should be allowed to 
modify or unlock data elements. In some repositories, it is 
difficult to restrict the creation of repository objects. If this 
is the case, it may be acceptable to let designers create data 
elements if these are reviewed and locked at the end of each 
day. Increased control can be obtained by having designers 
submit requests for new data elements to the repository 
administrator. This allows the repository manager to evalu- 
ate whether the new data element is justified, or whether an 
existing one should be used. 
Repository Maintenance 

a) Creating and Maintaining Data Elements 

Requests for data element changes can be forwarded 
using a database or paper-based system. Based on functional 
and technical knowledge, the repository administrator evalu- 
ates the requests and may involve other teams to make 
appropriate decisions. The database used to request data 
element changes during design and programming should be 
separate from the project's change request database. This 
will simplify and speed up the change process. When data 
elements have to be changed during system test, however, 
the impact can be much greater, and the regular change 
request database should be used. 

Whenever a data element is changed, impact analysts 
must be performed to understand the side-effects. Where- 
used reports are useful to determine these side-effects. The 
repository manager must be able to obtain the list of direct 
references and the list of all components affected indirectly 
(transitive closure). In the latter case, a message based on a 
record containing a group, which makes reference to a 
changed data element is considered to be indirectly affected 
by the change. When adding a data element, no functional 
equivalent must exist, because redundancy creates difficul- 
ties for impact analysis and future maintenance. 

b) Creating and Maintaining Other Repository Objects 
The objects related to dialog definitions, reports, 

messages, and so forth, are usually maintained by the 
designers and programmers. When the dialogs and report 
programs are tested, approved, and ready to be promoted to 
the system test environment, the related objects must be 
locked. This is the responsibility of the Repository Manage- 
ment team. 

Repository Validation and Mass Changes 

Keeping thousands of data elements consistent and in 
compliance with project standards requires a sustained 
effort. This daily effort is crucial to avoid a massive clean- 
up, which would be necessary if the repository manager ever 
lost control of the repository. 

Detailed, project-specific standards should exist for defin- 
ing repository objects. These standards can form the basis 
for a repository validation program, which can run through 
the entire repository and report on detected deviations from 
standards. In some cases, this program can also enforce the 
standard. 

Mass changes to the repository can be performed when 
the validation reports show the occurrence of many stan- 
dards violations that follow a common pattern. This may 
occur in cases where: 

Project standards have been incomplete 

Project standards have changed 

Repository management has been poor 

New objects have been imported from another repository 
Analysis, Reports, and Queries 

Certain reports should be run daily, such as the list of new 
data elements or modified data elements. These reports can 
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serve as an audit trail of changes and can be used to Storage management 

communicate changes to the entire team. Procedures should Metadata management 

specify which reports are run daily and what their dislribu- Version control 

tion should be. „ ^ 

The Repository Management team performs certain 5 ^ ^ 

analyses repeatedly. Standard analyses such as impact analy- Storage management concerns the methods of stormg and 

ses should be specified in detaU to facilitate staffing flex- meving media content. The cost of data storage may be 

-^j decreasmg, but it is still the case that for large volumes of 

' When supporting specific kinds of repository analysis, the S'''^ u '' ""^'"^ uneconomical to store everything on-line- 
Repository Management team can provide custom reports or lO ^^'^ processes must be implemented to manage 
ad hoc queries that satisfy particular needs. ^^^^^ ^^^^ ^^«!^^^ « °?^y transitioned 
Folder Management (204) ^°°ther. There are three ways to store 

It is important to set up and communicate a detailed folder 

structure with specified access rights from the beginning. On-line (Instant access, for example, hard disk) 

Contentsof folders must be checked regularly to ensure that 15 Near-line (delayed access, for example, CD-ROM 

folders contain what they are supposed to. jukebox) 

Two main strategies exist. (^^j^^^^l ^^^^^ example, CDs or tapes on 

Folders can be organized by type of component so that shelves) 

one folder contains all the include files, one folder when deciding on where media content should be stored, 

contains the source modules, one folder contains 20 ^^^^ always a trade-off between accessibility and cost 

executables, and so on. (on-line storage being the most accessible and most 

Folders can also be organized functionally so that all the expensive, and off-line the cheapest but least accessible), 

common components reside in one folder and each The decision of which method to use for which data may 

application area stores its components in its own folder. depend on a combination of its type, volume, version (i.e. 

Choosing the strategy depends on how components are latest or historic) and accessibility requirements, 

named, on the number of components, and oa the tools used. Metadata Management 

If naming standards make it easy to identify the component ^^^^ ^^^^ ^^^-^ ^^^^ ^ ^eing stored is an important 

type (for example, by using suffixes), orgamzing them by commodity that must be managed. As the volume of media 

functional area is generaUy useftU and straigjitfonvard to ^^^^^^^ ^^^^^ ^-^^^ ^t>le to understand character- 

admmister. Some tools assume that closely hnked files (for ^^-^ ^^^^ ^^^^ ^^^^^ ^ ^^j^ ^^^^^^ -j correctly, 

example, source and object modules) reside in the same Examples of metadata include: 

folder. ^ 

Another important distinaion is the one between work in Media type (for example, MPEG video, JPEG image) 

progress and completed documents that have been approved. Media settings (for example, sample rate, resolution. 

This distinction can be supported by a folder structure with compression attributes) 

carefully chosen access rigiits. Usage details (which module uses the content) 

This distinction makes it easy to retrieve a consistent copy ^edia source (for example. Source, author, creation date) 

of project documentation for someone who is new to the r i • t /c i u *u .u • 

" Legal iniormation (for example, whether the media is 

project. ^ • ht 

While scratch folders may be usefiil in certain contexts, ^ , PY^S ^ ) 

the proliferation of miscellaneous folders with cryptic names Version Control 

can make it very difficult to navigate the information. Some As with standard development code, when media content 

useful guidelines inchide: is created and edited, a revision history of changes should be 

Keep the folder structure under central control. retained. This way, if it is necessary to revert to an original 

. 1 r 1 J n * * r 1 J piccc of media content, it is not necessary to go all the way 

Within personal folders, allow users to create any folder f,..!. -i i. c^j- 

stnicUire back to the onginal source (which in the case ot nndmg an 

image in a CD-ROM library containing 10,000 images, for 

Qearly assign ownership for the contents of each folder. example, could be a difficult task). In practice, this may 

Document each folder, either in a central location, or in ^ean storing the original and final copies of media 

the form of a readme type file within the folder itself. 50 (especiaUy where volume is an issue). For this reason, a 

The high-level documentation should include the pur- process for managing multiple versions of media content 

pose of the folder and the kinds of contents it should must be put into place. 

The more advanced media content management tools may 

Perform regular clean-up, by backing up redundant or provide much of the functionality required to support these 

misplaced files and then removmg them. 55 processes, but where this is not the case, the processes must 

Media Content Management (206) implemented manually. 

The unique nature of media content means that it cannot . ^e . j^^^ Management 

be treated in the same way as ^standard' formats, such as „„ , ,. . . . . ^ 

source code or design documentation. The major differen- ^^e^ ^'^^ '\ ^ ^^f ^^at content 

tiating factors are its sheer volume (media files can range 60 °^^y ^f^^":^ °^Py"Sh.^ ^^^f' ^ ^"^P^^ant that the 

from a Kilobyte to multiple Gigabytes), and the complexity ^^^f implications surrounding ail content m the system is 

of its associated fomiats (i.e. it is not easy to *look into' a understood, and where necessary, royalties paid to the 

media file and understand its contents). For this reason, appropriate parties, 

some of the processes that support multimedia content Object Management (208) 

management must be handled differently. The three major 65 Object Management processes are very similar to those 

processes that are required to support media content man- involved with Repository Management. However, they 

agement are: should promote reuse through specific processes: 
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Design review 

Gasses and components packaging for reuse 

Common componenis maintenance and upgrade 
Quality Management (264) 

Quality Management is described at length in the Busi- 
ness Integration Methodology (BIM). 

The Quality Management processes are covered by the 
following tasks: 

0623 — Define Quality Management Approach 

0732 — Implement Quality Management Approach 

The objective of these tasks is to ensure that, early in the 
life of a program, program leadership explicitly defines what 
quality means for the program. This results in the production 
of the quality plan. Then the infrastructure and processes are 
put in place to ensure delivery of a quaUty program. 

The Quality Management Approach defines the following 
processes: 

Expectation Management 

Quality Verification 

Process Management 

Metrics 

Continuous Improvement 
Rewards and Recognition 
Training and Orientation 

Focus here is on those processes that have a direct impact 
on IDEA and its components (that is, Systems Building and 
the management processes). 
Expectation Management Process 

Expectations can be thought of as quality objectives 
expressed in measurable terms such as: 

Functionality 

Reliability 

UsabiHty 

EflSciency 

Maintainability 

Portability 

Security 
Quality Verification Process 

The targets for quality verification should be defined. 
Processes and deliverables are key candidates. 

In development terms, the V-model is the preferred 
method by which the quality verification process is man- 
aged. The V-model ensures that deliverables are verified, 
validated, and tested. It is based on the concept of stage 
containment (enforcing for a given deliverable the identifi- 
cation of the problems before it goes to the next stage) and 
entry and exit criteria (describes conditions in which a 
deliverable passes from one stage to another). 

The quality verification process owner may not be respon- 
sible for executing the V-model, but is responsible for 
making sure that the V-model is in place and complied with. 
Metrics Process (210) 

To fine-tune the development process, the important qual- 
ity attributes must be measured. Sample metrics include: 

Development environment availability 

Time needed for a new user to learn to use a function of 
the development environment 

User error rate per function 

User satisfaction per function 

Code complexity 

Code structure 

Productivity 
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Average number of defects per design packet at the 

moment construction starts 
Average number of defects per program at the time of its 

first migration to system test 
5 Once the key metrics are agreed upon, procedures must be 
put in place to: 

Perform the measurements (these should flow from the 

development processes in a natural way) 
Compare results with the goals documented in the quality 

plan 

Analyze deviations, with key focus on the process that 

caused the deviation 
Adjust the processes so that similar deviations do not 
15 occiu" in the future 

Continuous Improvement Process (212) 

The first stage of the Continuous Improvement Process 
(CIP) is to capture continuous improvement opportunities. 
These may include: 
20 Gaps identified by metrics 

Analysis of program performance-internal quahty verifi- 
cation results 
Process reviews 
25 Capability Maturity Model (CMM) assessments (See 
Standards and Procedures) 
Suggestions made by program team members; for 

example, through a suggestion box 
The CIP then plans and manages improvement related 
30 activities such as: 

Define explicit criteria for assigning priority 

Consider raising the priority of low-priority opportunities 

that can be completed quickly 
Maintain a mix of high-priority and sure successes to 

ensure the continued momentum 
of the Continuous Improvement program 
Define the opportunity selection process 
Identify the resource allocation process 
Define the scheduling process 
Identify how the effort will be monitored 
Identify the procedure for communicating results to the 
organization 

45 Establish a continuous improvement organization to sup- 
port the process 
Prioritize and classify opportunities 
Select projects 

Allocate resources and scheduling 
Monitor effort 

Support a standard process improvement process across 
the project 

While maintaining quality at a program level, the Quality 
55 Management team must liaise with each of the organiza- 
tional units within the development environment in order to 
monitor the quality management processes within these 
units. 

Standards and Procedures 
60 The Capabihty Maturity Model (CMM) for Software 
describes the software engineering and management prac- 
tices that characterize organizations as they mature their 
processes for developing and maintaining software. 

The CMM provides a software organization with guid- 
es ance on how to gain control over their processes for devel- 
oping and maintaining software and how to evolve toward a 
culture of software engineering and management excellence. 
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The model defines five levels of software process maturity 
as well as how to move from one level to the level above. 

For more details, refer to Consistently Delivering Value: 
The CMM — How to Help Your Project Measure Up. 

The V-model is a framework that promotes stage contain- 
ment by organizing the verification, validation, and testing 
in and across all the methodology elements throughout the 
delivery phase of the Business Integration Methodology. 

For more details, please refer to the V-model overview 
job-aid in the Business Integration Methodology. 

The IMPROVE Job Aid (provided with the BIM Guide) 
describes the process for solving problems or improving a 
process. In this Job Aid, you will find an introduction to the 
five step process your team can use to solve both simple and 
complex problems. The Quality Action Team (QAT) is 
responsible for applying IMPROVE to improve a process or 
solve a problem. 

Program and Project Management (274) 
Program Management 

Program Management focuses on the continuous over- 
sight needed to support the delivery of business capability 
through multiple projects and releases. Appropriate 
disciplines, techniques, and tools are used to plan and 
organize the work, and to manage the incremental delivery 
of the new business capability. 

Program Management consists of three major activities, 
each split into a number of task packages. 

a) Plan Program 

0610 — Understand Program Expectations 

0620 — Plan Management Processes 

0640 — Develop Program Master Plan 

0650 — Design Initial Teamwork Environment* 

0670— Plan Delivery 

0680— Create Program Plan 

b) Mobilize Program 

0710 — Obtain and Deploy Resources 
0730 — Implement Management EProcesses 
0750 — Establish Program Management OfiBce 
0770 — Implement Initial Teamwork Environment* 
0790 — Establish Orientation and Training 

c) Manage and Improve Program 
0810— Direct Program 

0820 — Execute Management Processes 

0830 — Analyze Program Performance 

0840 — Plan and Implement Program Improvements 

0850 — Operate Program Management OfiBce 

0860— Authorize Build and Test 

0870 — Authorize Deployment 

0880 — Operate Team Work Environment* 

'The Team Work environment, in the domain of tbe development environ- 
ment, includes those parts of the development environment ^^^ch are 
consistent across the entire program (e.g. Collaborative tools) 

0890— Conduct Program Close-Out 
Project Management 

Project Management focuses on providing specific deliv- 
erables through balanced management of scope, quality, 
effort, risk, and schedule. Project Management processes 
follow a cycle of planning the project's execution, organiz- 
ing its resources, and controlling its work. The Project 
Management team oversees all other teams within the devel- 
opment environment. 

Project Management comprises a single activity contain- 
ing a number of task packages. 
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a) Plan and Manage Project 
0920 — Plan Project Execution 
0940 — Organize Project Resources 
0960— Control Project Work 
5 0990 — Complete Project 
Configuration Management (270) 

Configuration Management is not only the management 
of the components in a given environment to ensure that they 
collectively satisfy given requirements, but it is the man- 
10 agemenl of the environment itself. The environment consists 
not only of system components, but also of the maintenance 
of these components and the hardware, software, processes, 
procedures, standards, and policies that govern the environ- 
ment. 

Configuration Management in systems building consists 
of four major interdependencies: 
Packaging 
Version control 214 
Migration conU-ol 216 
Change control 218 
Standards and Procedures 
a) Padcaging Plan 

Packaging is the combination of systems software and 
application component configurations (source code, execut- 
able modules, DDL and scripts, HTML) together with their 
respective documentation. It may also include the test-data, 
test scripts, and other components that must be aligned with 
a given version of the configuration. Packaging allows the 
grouping of components into deliverable packets of appli- 
cation software that can be developed, tested, and eventually 
delivered to the production environment. Packaging defines 
the underlying architecture that drives version, change, and 
migration control. Each of these control processes defines 
how changes to configuration packages are versioned and 
migrated to the various development and test phases in the 
systems development life cycle. ' 

A sample packaging strategy would take into consider- 
ation some of the following factors in determining a unique 
method to handle a given configuration packet in terms of 
version, change, and migration control: 

Base package type — identifies the various types of appli- 
cation components that are developed during systems 
building such as executables, JCL, HTML scripts, and 
Java applets. 

Package release type — identifies the types of commonal- 
ity that components can have. There are usually four 
basic types of components that are developed during 
systems building: 
Technology architecture packages — these packages are 
developed by tbe Technology Architecture team and are 
used by all other projects in a program 
Program- wide packages — these packages are developed 
by the Application Development teams but are used by 
other projects in the program. They are common com- 
ponents that are not owned by the Technology Archi- 
tecture team 

Application common packages — these packages are 
developed by the Application Development team and 
are used internally on the project by application devel- 
opers 

Application packages — these packages are the most rudi- 
mentary of all packages developed. They consist of 
basic application components developed by application 
developer 

Package platform type — identifies the eventual delivery 
platform of the package. Identifying this early on in 
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development and encapsuJatiDg this information within development life cycle. The application developers can then 
the package definition, allows developers to envisage develop 606, assembly test 608, and system test 610 their 
the production environment at an early stage during the components before user acceptance tests 612. The model is 
systems development life cycle. a temporal one and thus suggests that architecture must be 
Given these three basic package definitions, a coofigura- 5 present at a given stage before the introduction of applica- 
tion management cube can be defined, which uniquely components. 

identifies version, change, and migration control character- The version control plan must align with the migration 

istics of a given package. The cube can be used to implement control plan. The version control plan defines the points 

a table-driven configuration management control system for where version control activities will take place. In the above 

all software developed on the program. The configuration lo example, version control will take place at the development 

control system consists of version and migration control. stages, architecnire development and unit test, and applica- 

Therefore, the cube defines all processes associated with tion development and unit test. 

version control and migration of a package. Migration control defines how these version control con- 

b) Version Control (214) figuration packages will be migrated successfully from one 
Version control and compatibility are key considerations 15 stage to the next until the package is eventually released to 

when managing these packages. Note that version control production environment, 

not only applies to software components, but also to all Change control (218) 

components of a given package, including test scripts, test Change requests as a consequence of changing require- 

data, and design documentation. It is also of great impor- ments and changes requested due to nonconformities (or 

tance to keep track of which version is in which environ- 20 defects), either in the application software, or in the system 

ment. If incompatibilities are discovered, it must always be software must be analyzed, authorized, scheduled, staffed, 

possible to "roll back"* to a previous consistent state, that is, tracked in a defined way. What, why, when, and who 

to revert to an earlier version of one or more components. It made a change must be tracked from the point of analysis to 

must be possible to define releases of a configuration — a list reintroduction of the defective or changed component at 

of version numbers, one for each component of the package 25 *® appropriate stage. Change control therefore governs 

which together form a consistent configuration. The smallest what software component is changed, version controlled, 

unit that can be version controlled should be the package as when it is remigrated to a given development stage. It 

defined in the packaging plan. This ensures that the lowest is important to link the general change request with the 

common denominator in all version control activities is requests produced during formal testing phases. This makes 

managed at the package level. 30 the processes clearer. 

c) Migration Control (216) Configuration Management becomes more complex in a 
A systems building environment can have many devel- component-based development environment as the system is 

opmenl and test stages. On a large project these may include: broken down to a greater level of granularity. 

Development and unit test ^^^^^ Management (268) 

Assembl test Release Management involves coordinating activities that 

contribute to a release (for example, cross-project 
ystem test management) and the coordination of products that contrib- 
Integration test ^ release (such as architecture, integration, and 
User acceptance test packaging). It is concerned with managing a single release 
Migration of packages or consistent configurations firom ^ rather than cross-release management. The Release Man- 
one stage to another is a central part of Configuration agement approach documents critical decisions regarding 
Management. The key to successful migration is the knowl- the management, tracking, and integrity of all components 
edgeofwhatconstituteseachstage. Examples of migration and configurations within a given release. The Release 
include: Management approach must be closely coordinated with the 
Migration from development and unit test to system test ^5 definition of the Configuration Management approach and 
Migration from user acceptance test to production the Problem Management approach. Release Management 
Migration of development tools from the Technology involves two main components: 

Architecture team to the developers on the project The coordination of activities that contribute to a release 
Migration of architecture components firom the Technol- The coordination of products that contribute to a release 
ogy Architecture team to the developers on the project 50 The coordination of products that contribute to a release 
Stages and their constituents exist as a result of certain is the maintenance of a bill of materials for a release. It is an 
user and technical requirements. The technical requirements inventory of all software and hardware components that are 
are derived from the user requirements. It is crucial to related to a given release. The development environment is 
develop a migration plan that maps out the progression on directly affected by the Release Management strategy. The 
configuration packages throughout the systems development 55 way a program decides to plan releases affects the complex- 
life cycle. FIG. 6 is an illustration showing a model migra- ity of the development environment. It should be noted that 
tion plan in accordance with one embodiment of the present delivering a system in a series of releases significantly 
invention. increases the effort. 

The FIG, 6 model allows the development and testing of Standards and Procedures 

architecture components independent of application compo- 60 If the release plan dictates that there will be parallel 

nents. The Technology Architecture team can develop 600, development of two releases of software, the development 

assembly test 602, and system test 604 their components environment and configuration management must be able to 

before de five ring them to the development environment for support the release plan. In the most general development 

the application developers. This ensures that the architecture case, a program can have a single release capability mecha- 

is thoroughly tested before being used by the AppUcation 65 nism 700 but must simultaneously perform maintenance 

teams. The model also illustrates the progression of archi- activities 702 for components that are in production 704. 

lecture and application components through the systems There must be an ability for the program to design, build. 
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and lest the applications for production. FIG. 7 is an illus- High-quality support for developers 

tration showing a single release capability development Significant experience with the operations management 

pipeline in accordance with one embodiment of the present tools in an environment, which is generally smaller and 

invention. which carries lower risk than the full production envi- 

The ability to perform all development stages for a given ^ ronment 

release can be defined as a development pipeline. The ^h^ «'"'''y, '''^ environmeni management 

,. • . f 11 J 1 * J * *• f approach before production roll-out 

pipeune consists of all development and testing stages . '^'^ , , . . . • • i 

,1 * J. 4- In some respects, the development envu-onment IS simpler 

necessary to release the software to production. *l *u ^ *• * t. • r i 

than the production environment It is, tor example, gener- 
The pipehne strategy of a program depends directly on the ^^^^^^^ t^^ms of the number of hardware components 
release strategy. A program is potentially developed on three and the number of locations. In other respects, however, the 
different timelines; development environment is more complex. For example, 
Short term 800 — production bug fixes t^e amount of change in this environment is generally higher 
Middle term 802-production service packs the production environment. In fact, the enviromnent 
^ ^ can be so fluid that extreme care must be taken to maintain 
Long term 804— new releases of software i5 control. On a laige engagement, one dedicated technical 
To support this release plan, the development environ- support person per ten designers and programmers is rec- 
ment must be separated into pipelines that are replicas of a ommended. The greatest need for technical support is gen- 
single migration path to production 704. A pipeline consists erally during detailed design and programming. It is, 
of all the necessary development and testing stages required however, necessary to start building the technical support 
to deliver a piece of software to production. Therefore, 20 function before detailed design. 

because of simultaneous development and testing of three All processes that are performed by the Environment 

code bases, there needs to be three development and testing management team must be documented in a centralized 

pipelines that deliver software to production. database that allows quick and easy reference. 

The pipelines must be capable of allowing the developer Service Management (222) 

to design, build, and test applications as well as architecture 25 Service Management provides the interface between the 

components. FIG. 8 is an illustration showing a multiple Environment Management team, the Development teams, 

release capability development pipeline in accordance with and external vendors or service providers. It manages the 

one embodiment of the present invention. level of service that is provided to the developers. In order 

As can be derived from the above illustrations, the more to maintain this service, three areas must be managed: 

flexible a release plan, the more complex the development ^0 Management of Service Level Agreements (SLAs) 

environment. As the number of development pipelines Management of Operations Level Agreements (OLAs) 

increase, the complexity of working in the development Heln Desk 

environment also increases. Ail development environment g^^j^ j^^^j Agreements 

tools must support the pipehning strategy and so must the ,^ ^^^^ ,^ ,^ ^ ^ jj,^ development work 

configuration management and problem management pro- 35 ^ ^^^^j ^ g^^;^ ^e^^, Agreement (SLA) must be in 

cesses. The pipehne strategy for a program must mcorporate ^^^^^^ Management group (typicaUy part 

code base synchronization. Code base synchromzaUon must „j Environment Management team) and the developers, 

occur among the three pipelmes to ensure that the three code ^ ^^^^^ ^^^^^ components of the development 

bases eventually result in one version m production. FIG. 9 enviromnent, this agreement should be kept simple. It 

B ail Illustration showing a multiple release capabUity « shouW specify the following: 

development pipeline with code base synchronization ™_ i ^ . ^ - 

*L 1- ■ * The responsibility of the Environment Management team 

among three pipeunes. Environment Management (266) t . 

Since the development environment is a produaion How developers should request techmcal support 

environment, it foUows that environment management must ^^^^ ^'^^^V ^^"^^ support wiU be serviced 

be planned, organized, and executed to ensure a predictable How the Environment Management team will notify 

and productive environment. The present invention can developers of environment changes such as changes to 

include a comprehensive frameworic for the Management Of databases and common technical modules. 

Distributed Environments (MODE), describing four central Specifications of service levels should be precise and the 

functions: service must be measurable. The SLA should also specify 

Managing Change 220 measure this service (for example, system response 

. ^„ times, request service times, backup frequencies). In 

5>ervice Management ZZZ addition, the SLA must be managed. It may have to be 

Service Planning 224 modified as the environment changes, and it must be 

Systems Management 226 reviewed with developers on a regular basis to see if the 

MODE provides an excellent framework for specifying 55 service level is adequate, 

the management responsibilities that apply to the develop- a) Operations Level Agreement Management 

ment environment. These responsibilities are often assigned The Environment Management team is responsible for 

to the technical group, but as discussed above, there are providing the specified level of service, but frequently relies 

benefits associated with establishing a dedicated environ- on external vendors and suppliers to perform certain tasks, 

ment management team. 60 For example, hardware service is typically provided by the 

The Environment Management component described here hardware vendor. To provide the agreed level of service to 

uses MODE as a framework, adopts MODE terminology, the developers, the Environment Management team must 

and focuses on those management tasks, which are particu- ensure that external vendors provide their services as 

larly important in the development environment. required. This generally means establishing a contract with 

Adopting a structured approach to environment 65 the vendor and following up that the contract is respected, 
management, which applies the same principles to develop- As the relationship between the Environment Manage- 
ment as it does to production, has several advantages: ment team and external vendors becomes less formalized 
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(for example, lotemel Service Providers, mass market soft- improvement effort may focus on providing the same level 

ware vendors), it becomes more difficult to provide guaran- of service with fewer resources, or on providing better 

tees on the level of service that will be delivered service. An important part of quality management is ensur- 

b) Help Desk ing that the Environment Management team understands the 
The Help Desk function is an important part of the 5 key performance indicators for service delivery, that these 

interface between the Service Management group and the indicators are monitored, and that all personnel are 

developers. The Help Desk makes sure that questions are adequately equipped with the tools and training to fill their 

answered and requests serviced in a timely manner by the responsibilities. While the entire team is responsible for 

right people. In a complex, leading-edge environment, the delivering quality, the responsibility for Quality manage- 

Help Desk is crucial to maintaining productivity. The Help lo ment should be assigned to a specific individual on the 

Desk needs particular focus when: Environment Management team. 

The system software is immature Systems Management (226) 

The development environment is weakly integrated ^^^^ ^^^^^^^ ^y^'^"^^ Management into: 

TTie environment is heterogeneous Production control 

The amount of newly released custom infrastructure is Monitoring 

l^fge Failure control 

The developers are less experienced Security management 

While supervisors and coordinators who work with the Staffing considerations 

developers may alleviate the impact of these factors, the 20 Production Control 

more difficult questions must be resolved by the Environ- In the development environment, a number of activities 

ment Management group. As some of these will be repeat must be performed according to schedule, including: 

questions, the ability to log the question, the analysis, and Reorganization of databases, including the repository 

the result in a strucmred way provides the basis for per- Rerunning of database statistics 

forming smart searches and answering the question quickly. 25 ^ . • . t 

Repeat questions may also trigger: Performing backups 

Ajj ** 1* • • Transportation of backups off-site 

Additional trammg ^ ^ 

XI J O c ' *• * ■ Performing periodical file transfers between 

Modifications of existing trammg . , • 
7 . . T. . „ , . environments/sites 

Additional entnes m a technical hmts database ^ - - ^ • 

Preventive maintenance of equipment 

Changes m tools, procedures, and responsibilities activities can be scheduled and performed 

Efficient searches in the Help Desk database can m some automatically, but must have some level of manual control 

cases, be greatly facilitated by extending the basic function- ^ ^^^^^ ^^^^ ^^^^^^^^ correctly. Control tasks may 

ahty of the Help Desk tool. This can be achieved, for include checking and archiving activity logs. Standards and 

example, by adding a smart word search capabUity on top of 3s procedures that describe the control function must be estab- 

the Help Desk history database. fished 

Comprehensive training must be given to Help Desk Monitorine 

personnel in order to ensure the best possible level of service Environment Management team must systematically 

to the developers. , . „ , monitor the development environment to ensure that it is 

In addition to servmg mternal project needs, the Help 40 stable, provides adequate response times, and satisfies the 

Desk must be prepared to coordmate the activities of exter- ^^^^ developers. This monitoring involves looking at 

nal suppliers to solve problems. This occurs when several ^^^^^ extrapolating them to anticipate problems with 

new versions of hardware and system software are ^^j^ capacity, system performance, network traffic, and so 

introduced, and compatibility issues arise. Part of the coor- forth 

dination is the tracking of request IDs, which refer to the 45 p^iiure Control 

same question but which are assigned differently by each p^-j^^^ ^^^^ ^ corrected quickly to restore ser- 

suppfier. yic&. The time needed to restore service is affected by the 

To manage communication with external vendors a con- ^^^^^^ f^^H ,^ ^^^^ ^^^^^ 

tacts database with the foUowmg mformation is useful: ^^^^^ ^-^^ ^ shortened by allowing remote admin- 
Company name 50 istration of system components. 
Products supplied Security Management 
Details on support arrangements Security management involves; 
Address, phone and fax numbers Defining security requirements 
Main contact 55 Preventing security breaches 
Secondary contacts Limiting the effect of security breaches 
Regional office address/fax/phone/contacts Detecting security breaches 
World headquarters address/fax^hone/contacts '^'"^ 1^ "^"^'^^ 

Basedonthisinformation,itisusefultologtheexchaDges ^ ^V^^^S^* ^^^'''^^^ '''^^ mexperienced 

with the external company, indicating: developers, perhaps new to the projecU can wreak havoc to 

the system under development by inadvertently deleting or 

^^^^ modifying system components. Focus must be on defining 

Individuals involved access rights so that developers have the right level of access 

Key information exchanged (read/write) to all the information that is useful and relevant 

c) Quality Management 65 to their work. 

Defining the SLA, with its specific, measurable criteria, is With the opportunity to cormect development environ- 

the basis for continuous improvement. The continuous ments to the internet comes new risks. There is a potential 
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for security breaches or ihe transfer of viruses and other Well planned testing 

malicious progranis. In extreme situations, where security is Sufficient training for new tools or changes to existing 

of great importance, it may be prudent to isolate the devel- tools 

opment environment, and allow Internet access only via a Planning for change includes choosing options based on 
dial-up connection on stand-alone machines. The overlap of 5 a thorough imderslanding of the positive and negative 
responsibility for Security Management between the Envi- impacts of change to the environment. Changes to the 
ronment Management team and the Security Management development environments should be analyzed and planned 
team will need to be defined at the program level. orderly releases rather than a stream of small modi- 
Outsourcing Considerations ficalions. Changes should be packaged into releases, and 
In the development enviromnent, it may be possible to lO each new release of the development environment should be 
outsource certain Systems Management tasks. For example, ^^^^^ developmg a small, but representative part of the 
the LAN supplier may be willing to take responsibiUty for system usmg the new environment. Ideally, this test should 
LAN support, upgrades, and so on. Similarly, an existing performed by real developers rather than by the Envi- 
data processing center may be willing to take responsibUity ^^^^^^ Management team. This may be very helpful m 
for host operations. Such agreements are very beneficial and 15 Z'^^' .^'^"^^ 
make it possible to use project team members more effec- Strategic Planning 

lively. However, outsourcing the development environment . Strategic plannmg is traditionally regarded as bemg less 
carries a risk, which can be mitigated by defining a Service important m a development environment than m the pix)- 
Level Agreement with the provider. This will generally be environment, mamly because the development envi- 
very similar to the SLA established between the Environ- 20 ^ ^ temporary entity that does not 
ment Management team and the developers. One important considerations. This may be chang- 
difference is that punitive measures (to be applied if the SLA however, with the concept of the enterpnse-wide devel- 
is not respected) must be specified to ensure that outside °P°^^"» environment—a single, genenc development envi- 
suppUers are strongly motivated to abide by the agreement. JO""^.^^^ architecture that is tailored to each specific project. 
Service Planning (224) 25 strategic planning for the development envi- 
MODE divides Service Planning into: '^^"'"^'^^ ^^^^"^ important if the environment is to evolve. 
„ . . . r.1 * allow the organization to remain competitive. Strategic 
Service Management Planmng ^^^^^^^ environment management function may, for 
Systems Management Planning example, include such questions as support for multi-site 
Managing Change Plaiming development and coordination of multi-sourced systems 
Strategic Planning management. 
All these planning stages apply in the development envi- Managing Change (220) 
ronment and are analogous to the kind of planning that must 'The development environment is subject to constant 
occur in the business application's production environment. change (for example, the addition of new tools, or changes 
One of the most important success factors when providing 35 to code libraries), which needs to be managed carefully. The 
technical support is being proaaive and anticipating the Managing Change component comprises three sub- 
need for intervention. components: Controlling Change, Testing Change, and 
Service Management Planning Implementing Change. 

Once the SLA is defiried, the resources required for Controlling Change 
delivering the service can be specified. Questions to address 40 ^^^^ planning for and scheduling change, it must be 
include the staffing of these resources and training to ensure controlled. This ties in closely with Configuration Manage- 
that they are equipped to deliver service as agreed. ^aent (see Processes — Configuration Management). 
Systems Management Planning Testing Change 

Daily tasks must be specified, assigned, and followed up. Thorough testing is required to reduce the risk of produc- 

Systems management planning determines who is respon- 45 tivity loss due to environment changes. Techniques com- 

sible and how follow-up is performed. monly used include: 

Managing Change Planning Careful scheduling of events to minimize disruptions 

Managing change planning is of great importance in the (typically weekends and evenings are used to enable a 

development environment. During a large project, several strictly controlled test of new components released to 

very significant changes to the development environment 59 the design and construction environment), 

must be accommodated. They include: Rigorous testing of Environment Management tools 

New hardware themselves. This test must be as rigorous as the testing 

Rewiring of the network execution environment 

New development software ^ hardware and systems software acceptance test envi- 

New releases of existing development software ronment where components from external suppliers are 

^ . ^ , validated before the component is accepted into the 

New releases of mfrastructure components (custom-built environment 

technology architecture) ^ . . One or more separate architecture build and test environ- 

The release of these components mto the environment *t- jcj.li. 

, . • • , J- - ments where new or modified custom -buiU components 

requires very careful planning to ensure minimal disruption ^„ . . , ^ ^ u r *l j 1 

r ji T-L- 1 j 60 can be thoroughly verified before they are made avail- 

for developers. Techmques commonly used include: ^j^^^ * 

FaUback options if a new component does not function as i„ ^^dition to reducing risk, testing should also verify that 

planned expected positive benefits of the change are indeed 

Partial rollout to a sub-team to limit the consequences if obtained. 

a component does not work as planned 55 Implementing Change 

Ample information to developers about timeframes for After planning and testing the change to be introduced, it 

rollout and expected effects of new components must be implemented. The most common kinds of change in 
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the development environment are the introduction of addi- changes. Small corrections may not require explicit design, 

tional hardware, new releases of databases, subroutines and and small enhancements may not require any high-level 

infrastructure, and upgrades to tools. Each change imple- design. The shaded, elliptical labels in the above figure 

mentation should be viewed as continuous improvement so indicate how the development process can be entered 

thai any difficulties or inefficiencies are analyzed and result- 5 depending on the magnitude of the change, 

ing improvements are planned and implemented. To be The iterative nature of the development process is impor- 

effective over time, this requires that procedures be docu- tant since it implies that components of the development 

mented and regularly reviewed and enhanced. environment, which are put in place for design (for 

When the database is changed, new versions of test-data example), must be maintained, since they will continue to be 

must be developed and distributed. When infrastructure used until the end of system test and beyond. Multiple 

components are modified, they may have to be distributed releases of the business application may also be under 

across platforms, and the ripple-effects (for example, the concurrent development at different stages. This may lead to 

need for recompilation or code changes in affected very active use of design, construction, and testing tools at 

components) must be understood and coordinated. Some the same time, 

projects have experimented with incentives to ensure that Analysis & Design (228) 

the infrastructure components do not change too frequently. ^5 Analysis and design in this context, refer to the two 

One such strong incentive is to make the Architecture team Business Integration Methodology activities: 

responsible for all ripple effects and have them implement Desien Aoolication 

all the application level changes that result from an archi- ^ . _ . , , ^ 

lecture modification. Design Technology Infrastructure 

Problem Management (272) 20 P'**P^ '^'ffi'^'^" 

Problem Management is generally associated with the "ccu^ "p front. Tie sua:ess of the entire design effort 

discrepancies that result from the testing process, though it fP^"'^^ °" '>"^"y °f performed to gather, 

may also be applied to the management of design problems document, communicate, and analyze requirements m the 

detected during verification or validation steps. Problem "''^ Standards for how to document these rcquire- 

Management is a crucial process in the system development 25 "f"'* f« important. They faahtate communication, 

life cycle. It ensures that quality software is designed, which m turn, ensures a common view of the problem to be 

developed, and tested so that initial benefits defined in the solvedXommunicauon must be ensured wiihm the analysis 

business case are in fact reaUzed. A development environ- ^^"^ (possibly future) designers and 

ment must have a formally defined problem management programmers. ^ . , 

process to ensure that this objective is met. 30 Tool support may help enforce standards, and such tooU 

Formal problem tracking helps to control the analysis and disci^d under Tools-System Building-Analyse & 

design process by maintaining documentation of all prob- > ^. ... 

lems and their solutions. Problem tracking improves com- The design process mcludes numerous aaivities, which 
munication between developers and business range torn higWevel general consideraUons to low-level 
representatives, which is particularly helpful in minimizing 3S detailed issues The overall objective of design is to trans- 
misunderstandings at later stages of the development cycle. functional and technical specifications mto a blueprmt 
Such formal problem tracking also helps to facilitate the effectively guide construction 
solution process by formalizing a procedure for reviewing, While requirements analyse and specification 
acting on, and solving problems in a timely manner. By """^ ^''.t." I''^ ^y*'^'" must do, design addresses how 
circulating problem documentation to all affected parties, 40 «y^'«°> be constructed. Validatmg that the design 
management can minimize the risk of misunderstandings at ''""^"y """'f. '^.^ requirements for functionality, 
a later date. In addition, the documentation serves as an audit performance, rebabUity and usability is essenhal. 
trail to justify design and implementation decisions. ^he quaUty of the design process direcdy affects the 
It is, however, important to note that not only the software m='gD""de of the efforts required to construct and test the 
lhat is developed for business case benefits realization must 4S *yf f.^'^" as the mamteDance effort. Investments m 
have a formal problem tracking mechanism, but the devel- i'^^n^'g high-quality design standards and procedures and 
opment environment architecture must also have a formal integrating tools is therefore particularly miportant. It may, 
problem tracking mechanism. The development environ- for example, have a direct impact on the degree of reuse 
ment tools and processes support the design, development, achieved In addition, adequate training mugt be provided to 
testing, and delivery of quality software. Tlierefore, the 50 ensure that the designers make optimal use of the environ- 
foundations of design, build, and test must be stable and ment provided. 

problem free. All problems identified in the development , Informanon on how to approach system design can be 

enviromnent architecture must be tracked forraaUy and following Andersen Consultmg sources: 

solved as the development environment is also a production Delivery Vehicle Frameworks (see Technology Library) 

environment for developers. ss Network-Centric Architecture Framework (see Technol- 

System Building (278) ogy Library) 

Understanding the systems building process is important The Graphical User Interface Design GuideUnes (see 

since well defined development tasks and workflows form Technology Library) 

the basis for achieving high productivity and consistent Design Application Architecture (see ENACTS MKB 

process quality. Tools to support these processes may be 60 database) 

found in Tools — System Building. New tools and processes link detailed design and con- 

The development environment varies by segment of a stiuction more closely than before. To realize the expected 

systems development project. The following model is used benefits from repositories and code generation, the output 

when discussing different components of the development from detailed design must be exact and correct, leaving little 

environment. 65 room for interpretation. This requires careful quality control 

The development process is iterative and can be entered and very specific exit criteria associated with the completion 

at different stages depending on the complexity of the of detailed design. 
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It is important that the development environment accom- Window and report design standards 

modates concurrent effort in different areas. For example. Naming standards for design objects and documents 

parts of design may occur after system test starts, as in the Navigation standards 

case of an urgent change request, or when a significant Standards that specify the design techniques to use 

inconsistency is detected in system test. Some reverse engi- 5 Documentation standards that specify format 

neering work may also occur before design or during Technology infrastructure design standards that specify 

construction. ensure security, handle errors, and manipulate 

When standards, procedures, and tools are developed for context data 

a task, it is important to consider where the task belongs in while the standards focus on what to do during design, 

the sequence oftasksthatcontribute to the development. For 10 procedures focus on how to do it. Procedures must be in 

example, the use of a repository early in the development place to specify: 

process reduces the need for re-entering information while How to resolve hinctional and technical issues 

enhancmg consistency and facilitaUng standards comph- y^^-^^ ^^^j^ ^ ^ 

i^^il'i'. J TT 1 * _f T-i ■ How to perform design validation 

Usability and User Interface Design i5 „„ , ^ ... , . .... 

UsabiUty is an important (and often overlooked) consid- ^° "^'^'^^^ P^^^^™ functional and 

eration in system design. Usability is more than a weU- technical design reviews 

designed user interface— the way in which business pro- ^^^ign teams distnbuted across loca- 
cesses are modeled, how they are implemented within the 

system, and how they are presented to the user all contribute 20 Guidelines give assistance in areas where judgment is 

to the overall usability of the system. Usability is an iterative important and where standards are not easy to define, 

process of refinement that results in systems that are easy to Valuable guidelines may include: 

leara, efficient, and enjoyable. In the very broadest sense. Usability guidelines 

usability is the thoughtful, deliberate design approach that Style guidelines 

considers users throughout the solutions^building process, 25 Guidehoes on how to use a tool effectively 

from start to finish. For this reason, usability guidelines Sample design packet for each kind of system component 

should be defined and followed at every stage of system to be designed 

design. This, along with regular usability reviews and tests Designers must understand standards and procedures 

both internally, and by target user groups (by using other than the ones listed above. For example, repository 

prototypes), helps to reduce the risk of a poorly received 30 related standards are very important to designers. These 

system. standards are discussed in Processes — Information Manage- 

The User Interface has become increasingly important as ment (above), 

systems become more and more user- facing. As multimedia Implementation Considerations 

technologies evolve allowing the development of richer user a) Multi-site Development 

interfaces, so the design processes must adapt to reflect these 35 In the case of systems being developed by multiple parties 

new technologies. The processes that surround the design of or across multiple locations, it is vital that a process of 

media content are similar to that of regular system design, regular communication is implemented. This communica- 

and many of the same issues that apply to designing tradi- tion should involve all the parties involved in the design of 

lional user interfaces also apply to the design of media the system, and is usually conducted in the form of an audio 

content. The major change is the involvement of media 40 conference (see Tools — Collaboration). Through this 

content designers— a group of people not traditionally asso- process, it must be ensured that all parties are approaching 

ciated with system design and development. As their pres- problems from the same direction, and that they are thinking 

ence is relatively new to the scene of systems development, about the design in the same way. If this is not achieved, 

it is often the case that media content designers are not fiilly there is great potential for misunderstanding across teams, 

integrated into the development team — a potentially costly 45 which generally leads to a badly integrated system. In this 

mistake. It is important to ensure that media content design- type of situation, where parties are not working together on 

ers are involved in the design process at a very early stage, a day to day basis, it is also important that any definition 

and that they are fully integrated into the application design (requirements or design) is completely free of ambiguity (if 

and construction teams. anything is left open to interpretation, there is a high risk that 

The approach to Interface design is evolving as media 50 it will be misinterpreted). Practically, this means that quality 

technologies become more advanced. Modem media ere- controls on documentation need to be more stringent than on 

ation tools allow the development of not only media -rich a traditional single -site project 

interfaces, but also the functionality that lies behind them. Reverse Engineering (230) 

This means that the role of the media content designer may Reverse Engineering is a set of techniques used to assist 

now range from that of ^lesigning the look and feelof a user 55 in reusing existing system components. Most of the time, 

interface, to developing the entire presentation layer of an this work is perfonmed manually: one person studies thick 

application. In this situation, the role division between listings to understand data layouts and processing rules. The 

media designer and application developer becomes a diflB- person gradually builds a higher-level understanding of how 

cult one to define, reinforcing the argument for fully inte- the components work and interact, effectively reverse engi- 

grating media designers into the application development 60 neering the system into a conceptual model. It may be 

team. necessary to study certain pieces of code to understand how 

Standards and Procedures they work, but reverse engineering is not limited to code. For 

Well documented, comprehensive standards make design- example, these techniques might help understand the dala- 

ers more independent and enable them to produce more model of a legacy application, in order to better design the 

consistent, highquahty designs. Common standards include: 65 new applications that will coexist with it. 

Detailed specifications of deliverables from each design The process can be very time-consuming and is nolori- 

step ously difficuh to estimate. Tools to support the effort do 



05/16/2002, EAST Version: 1.03.0002 



us 6,370,573 Bl 

39 40 

exist, and have been used successfully to streamline the Package or Component Selection 

process. The main problem with such tools, however, is the Component Customization 

hasty (and erroneous) conclusion that tools automate every- Component Interfacing 

thing. They do not, just as design tools do not automate the See Tools — System Building — Packaged Component 

design process. Human intelligence is still required to drive 5 Integration for more details. 

the effort Standards and Procedures 

^ . , . , , _ A proven practice in the component-based development 

TTie supporting tools can, however, reduce the amount of ^^^j^^ ^^^^ ^^^^^^ purchased components, is to 

manual effort needed and significantly lessen the amount of u^^^p,, ^^^^^ ^ ^ encapsulate them so that the visible piece 

non value-added activities, such as "find all the places m a ^ny component remains fully controlled. This way, when 

program that affect the value of a given variable". ^ component is replaced (either for an update or because it 

The goal of a specific reverse engineering effort generaUy has proved to be defective), no other system components 

falls into one of the following categories: that refer to that component will need to be altered. 

To determine which parts of existing systems must be Construction (234) , e j j 

ijjLL L J Construction covers both generation of source code and 
replaced and wbch can be reused 15 ^^^^^ components as well as programming and unit test. It 

To determine how a particular component works in order may also involve help text creation and string test. As 

to design other components that interface with it construction is a large part of system building, the benefits 

To extract components for reuse of streamlining this process are significant. Since several 

To prepare for cleaning lip those parts of a system that wiU fPf^ construction are rather mechanical, it is often 

be retained fairly easy to simplify this process and to automate parts of 

In component-based development, a concept known as particularly if the design holds high quaUty. 

^ , . . „ J J r ... The arrival of Integrated Development Environments 

round-tnp reengmecnng provides the developer with a ^^^^^ simplified the automation of construction 

way of modifying a component model and generating the ^.o^esses to the degree that a single tool can manage the 
code, then at a later date modifying the code at predefined ^5 majority of the process. 

locations m the source code and regenerating, thus enabhng ^s with Analysis and Design, usabihty must not be 

the model to maintain a 2-way-syncronization. ignored in the construction of a system. Especially in the 

Note that components to be reverse engmeered can be ^ase of an iterative development approach, it is vital that 

both part of a custom-built system, or part of a software responsible for usability and target user groups are 

package. involved in regular reviews as the system is being devel- 

Projects dealing with the Year 2000 issues have had much oped 

experience in reengineering. Standards and Procedures 

Standards and Procedures Important standards include: 

The following reverse engineering guidelines should be Programming standards for each programming language, 

used as input when developing standards and procedures for 35 including procedural languages, job control languages, 

a particular context and data access languages 

Reverse engineering can provide important input both to documentation standards 

the design process and to the construction process. Important procedures include: 

Timing of the activities is therefore important. Code generation procedures, including pre-processing of 

The interplay between design and reverse engineering can |^ ^^^^ ^^^^ post-processing of the generated 

be intricate: a high-level design is needed to determine ^ 

which components from existing systems are of inter- Testmg procedures 

est. Once this is determined, these components can be Test-data handling and common test-data usage 

extracted, generalized, and fed into the detailed design Procedures for functional and technical reviews 

process as one source of information. Code review checklist 

The value of reuse will vary with the functional and Migration procedures which specify how to make corn- 
technical quality of the code. mon modules public 

It may be useful to clean up existing code before it is Important guidelines include: 
extracted for reuse. 50 Usability guidelines 

Tools should be chosen based on knowledge of the Shell usage guideUnes 

system, the amount of code to be processed, and the Tools usage guidelines 

experience of the personnel involved. T^st (236) 

The end should be kept in mind. With powerful tools, it System test is performed to validate that the gathering and 
may be tempting to "investigate for fun" rather than « transformation of information is complete and correct, 

extracting what is needed. ^ automauon progresses and an increasing number of 

. . ., , , , .... business processes are supported by computer systems. 

As with all other tools, adequate traimng is miportant. ^^^^^^ ^^^^ ^ ^^^^^^ ^^^^^^ p^^^j^^ ^^^^^^ 

Packaged Component Integration (232) interfaces to other systems is becoming an ever larger part 
Packaged Component Integration applies to the use of any 60 of systems test. Secondly, system test increasingly appUes to 

third party (or previously developed) technical components a new release of an existing system. In addition, it is worth 

that may be integrated into the target system. This can range noting that as design and construction is increasingly 

from simple components offering limited functionality automated, system lest is becoming a larger part of the total 

(worksheet or charting GUI components), to components development effort. 

haodfing a significant portion of the application architecture 65 Both of these factors increase the value of automated 

(data access components and firewalls). The process testing tools, given that the work associated with checking 

involves a number of stages: that system changes do not have unintended side-effects, is 
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becoming an ever larger pari of system test. Another trend Perform changes and refine impact analysis based on 

affecting system test is the demand for trace ability. added understanding 

Increasingly, users and management wish to know the Verify changes before re-submitting to system test 

purpose of a given test condition. This is answered by Migrate to system test based on updated impact analysis 

referring back to the design and to user requirements. 5 and re-lock components 

c » . « • 1 . f * J I See the Andersen Consulting V-model for more informa- 

System test is a very large part ot any systems develop- * 

raent effort and can, especially when requirements are implementation Considerations 

changing, exceed one third ofthe entire effort. Astreamlmed ^^^^^^ , information about the Reinventing 

environment, which enables high productivity is therefore of Testing Project (RTF)? 

utmost importance. b) What model of testing does the firm follow? 

IMPORTANT: When planning system test, it is vital that the The following is an overview of the firm's testing meth- 

testing of all target platforms is included in the test plan. For odology as documented by RTP. It describes the framework 

each platform that is supported by the system, there must be for the testing process, or the V-model of verification, 

a separate set of tests. validation, and testing. 

The necessity of impact of volume and stress testing early P^?P^ specifications being tested? 

in the development process is becoming more common, due , ^^""1^ an overview of the component test as 

t« th^ ™Kfr™t;^„ «f «™r tr.^K«r.i^«;^o #^io „,K.VK documented by RTP. It describes the testmg methods used to 

to the proliteration oi new technologies and tools which i j . *u j * -i j ^ - * u c 

. r . 1 J I. - • . validate the detailed design stage where program specifica- 

have uttle or no performance track record. It is unportant ^^^^ tested » -» r r 

ihat the performance and reliabiUty of such took and tecb- 20 component Test-A component test U the testing of an 

oologies IS established as early as possible m the project to individual piece of the solution. All components, 

avoid possible problems fiirther down the line. ^^^i^jj^g application programs, conversion programs. 

Component-based development may have an impact on and input/output modules, are subject to component 

the way in which testing should be perfornied. test. The objective is to ensure that the component 

Standards and Procedures implements the program specifications. At the end of 

System test relies heavily on configuration management, component test, all lines of code should have been 

„ * J r* * exercised, keeping in mind the specified functional and 

repository management, and quality management. i . ■ . 

^ & > ^ J to quahty requu"ements. 

Configuration management provides the basis for pro mot- d) Are systems design being tested? 

ing a configuration from the construction environment jq The following is an overview of the assembly test as 

to the system test environment. As test cycles are run documented by RTP. It describes the testing methods used to 

and fixes implemented, migration can become validate the technical design stage where system designs are 

complex, requiring flexible mechanisms for locking tested. 

and unlocking system components and analyzing the Assembly Test — The assembly test tests the interaction of 

impacts of change. 35 related components to ensure that the components. 

Information management, and in particular repository integrated, function properly. Assembly test 

. ^ ■ r *u • . ensures that data is passed correctly between screens m 

management, guarantees a correct view ot the interre- . u * u j .u . 

, . * . . . , * T^i. • • a conversation or batch process and that messages are 

lationships between system components, Ihis is . *iu^ i *j t-l 

^ ^ , < , passed correctly between a client and a server. I ne 

required to ensure that mipact analyses are complete specification tested is the technical design. The appli- 

and correct, which, m turn, makes for effective regres- 40 nation flow diagram within the technical design depicts 

sion testing. ijj^ assemblies, either on-line conversations or batch 

Quality management, together with well-defined stan- assemblies, that will be assembly tested. Testing is 

dards and procedures, ensures that the outputs from therefore organized by assembly rather than by busi- 

each test activity are documented at the right level of ness function. 

detail and fed back to the design and construction ^5 By the completion of assembly testing, the system should 

teams, in accordance with the quality plan. be technically sound, and data flow throughout the system 

Each of the following system test activities needs well- should be correct. Component and assembly testing ensures 

documented standards and procedures and should be sup- ^^at all transactions, database updates, and conversation 

ported by tools' flows function accurately. Testing in later stages will con- 

^ c / • * a c *L 50 centrate on user requirements and business processes. 

Promote configuration (migrate configurations from the indudine work flow, 

construction environment to the system test . . u 1. - ' * . jo 

e) Are benefits being tested? 

environment) / . * u • . * 

^ i) Are costs being tested? 

Run test cycle g) ^ intangibles being tested? 

Compare expected results and actual results 55 The foUowing is an overview of the benefits realization 

Log System Investigation Requests (SIRs) test as documented by RTP. It describes the testing methods 

Analyze deviations and identify components requiring vahdate the business case stage where benefits, 

change (either expected results, test-data, or system ^^sts, and other intangibles are tested. 

components) Benefits Realization Test — The benefits realization test 

Define Change Requests (CRs) and perform impact analy- 'hat the business case for the system will be met. 

The emphasis here is on measuring the benefits of the 

^ . . , . . new system, for example: increased productivity. 

Package those change requests that affect the same areas decreased lead times, or lower error rates. If the busi- 

and that naturally belong together, into change pack- ^j^^ ^^^^^^ realization test 

^^^^ 65 becomes more of a buyer signoff. 

Schedule and staff the changes Ideally, benefits realization test occurs prior to complete 

Unlock components for change deployment ofthe system and utiUzes the same environment 
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that was used for the service-level test piece of operational 
readiness test. Tools are put in place to collect data to prove 
the business case (e.g., count customer calls). A team of 
people to monitor the reports from the tools and prove that 
the business case is achieved is still needed. The size of the 5 
team depends upon the number of users and the degree to 
which tools can collect and report the data. The benefits 
realization test tests that the business case for the system will 
be met. The emphasis here is on measuring the benefits of 
the new system, for example: increased productivity, jq 
decreased lead times, or lower error rates. If the business 
case is not testable, the benefits realization test becomes 
more of a buyer signoff. 

h) Are quality requirements being tested? 

i) Are technical requirements being tested? 15 
j) Are functional/user requirements being tested? 

The following is an overview of the product and opera- 
tional readiness test as documented by the RTP. It describes 
the testing methods used to validate the requirement/ 
definition stage where quality, technical and functional/user 20 
requirements are tested. 

The Product Test — ^The product test tests the entire appli- 
cation to ensure that all ftmctional and quality require- 
ments have been met. Product testing may occur at 
multiple levels. The first level tests assemblies within 25 
an application. The next level tests applications within 
a system, and a final level tests systems within a 
solution. Within the multiple levels, the purpose is the 
same. 

The product lest tests the actual functionality of the 30 
solution as it supports the user requirements: the various 
cycles of transactions, the resolution of suspense items, the 
work flow within organizational units and among these 
units. The specification against which the product test is run 
includes all ftmctional and quality requirements. The testing 35 
is organized by business function. 

The Operational Readiness Test — ^The objective of the 
operational readiness test is to ensure that the applica- 
tion can be correctly deployed. The operational readi- 
ness test is also commonly known as the readiness test, 40 
roll -out test, release test, or the conversion test. The 
operational readiness test becomes especially key in 
client/server environments. It has four parts: 
Roll out test — ensures that the roll out procedures and 
programs can install the application in the production 45 
environment. 

Operations test — ensures that all operational proce- 
dures arc in place and acceptable, and that the 
production system can be operated by the personnel 
responsible for supporting production. 50 
Service level test — ensures that once the application is 
roUed out, it provides the level of service to the users 
as specified in the Service Level Agreement (SLA). 
Roll out verification — ensures that the application has 
been correctly rolled out at each site. This test, 55 
developed by the work cell or team performing 
, operational readiness test, should be executed during 
each site installation by the work cell or team in 
charge of the actual roll out of the application. 
The operational readiness test assumes a completely 60 
stable application and architecture in order for it to be 
successful, and therefore, is heavily reliant on the previous 
testing stages. 

The operational readiness test is the point in the devel- 
opment process where all the application development, 65 
architecture development, and preparation tasks come 
together. The operational readiness test ensures that the 



application and architecture can be installed and operated in 
order to meet the SLA. 
Development Tools Framework 

FIG. 10 is an illustration showing a Development Tools 
Framework in accordance with one embodiment of the 
present invention. The development environment is built 
upon an integrated set of tools and components, each sup- 
porting a specific task or set of tasks in the development 
process. As with processes and organization, the central 
component. System Building, is supported by the eight 
management components: 

Information Management tools 262 manage the informa- 
tion that supports the entire project — information that is 
tised both in systems building and in other management 
processes 

Security Management tools 276 enable the development 
of security components 

Quality Management tools 264 support all quafity man- 
agement processes 

Program and Project Management tools 274 assist the 
management teams in their daily work 

Environment Management tools 266 provide the facilities 
to maintain the development environment 

Release Management tools 278 manages the simultaneous 
development of multiple releases 

Configuration Management tools 270 cover the version 
control, migration control and change control of system 
components such as code and its associated documen- 
tation 

Problem Management tools 272 pertains to the problem 

tracking and solution process 
In addition, three other components are required to fully 
support development: 

Productivity tools 1002 provide the basic functionality 
required to create documents, spreadsheets, and simple 
graphics or diagrams 
Collaborative tools 1004 enable groups of people to 
communicate and to share information, helping them 
work together effectively, regardless of location 
Process Integration tools 1006 enforce the correct 
sequencing of tasks and tools in conformance with a 
pre-defined methodology 
An efficient development environment requires good 
tools. For general issues regarding tool selection, please 
refer to the general Produa Selection Considerations. 
Productivity (1002) 

While many tools are developed in order to support a 
specific task (for example, source code editor), there is a 
family of tools that are generally required across the board, 
often known as productivity tools or office automation tools. 
These tools, typically packaged as integrated suites of 
software, provide the basic functionality required to create 
documents, spreadsheets, and simple graphics or diagrams. 
More recently, the ability to access the Internet and browse 
electronic documentation has been added to the suite of 
productivity tools. 

Specifically, productivity tools include: 
Spreadsheet 
Word E*rocessor 
Graphics Editor 

Personal Organizer (may be linked to Group Scheduling) 
Methodology Browser 
Internet Access 

These tools are generally versatile enough to take the 
place of specialized tools (such as planning tools) in certain 
circumstances. 
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ImplemeDtation Considerations 

a) How secure does the developraenl eDvironment need to 
be? 

In environments where security is a factor, the way in 
which team menabers gain access to the Internet must be 
carefully considered. For example, on high security projects, 
it is often the case that isolated machines with a single 
dial-up connection provide the only way to access the 
Internet, thus ensuring that the development environment 
remains completely isolated. 

b) Are people using the Internet for its intended use? 
Studies have shown that employees spend a lot of time 

using their Internet access for purposes unrelated to work. 
Therefore, the benefits and damages of providing Internet 
access must be assessed . 
Collaboration (1004) 

It is well understood that both good communication and 
knowledge sharing are vital for the success of any team. As 
development projects get bigger and teams more distributed, 
it becomes increasingly difficult to maintain communication 
between project team members. Collaborative tools have 
been developed with this very purpose in mind — to enable 
groups of people to cxjmmunicate and to share information, 
helping them work together effectively, regardless of loca- 
tion. 

Implementation Considerations 

a) How distributed are the projea teams? 

On projects with development sites that are geographi- 
cally distributed, it is usually the case that communication 
by e-mail alone is not a sufficient substitute for meetings 
when attempting to coordinate the teams involved. In order 
to keep all teams updated and moving in the same direction, 
regular (for example, weekly) conference calls between all 
parties — <;haired by project management — is much more 
efficient. It is important that these conference calls are 
closely monitored, well prepared, and that the agenda is 
closely followed. Action points and commitments made 
during these calls must also be documented. Where issues 
arise that cannot be resolved using an audio conference 
(mually because the subject is based on a visual concept), 
video conferencing may be necessary. 
E-Mail (238) 

E-mail provides the capability of sending and receiving 
messages electronically. In addition to the ability to send 
simple ASCII text, e-mail systems usually provide the 
capability to attach binary files to messages. E-mail is a 
convenient tool for distributing information to a group of 
people, as it has the advantage of delivering content directly 
to the * mailbox' of each individual, rather than relying on 
individuals to access a central data repository in order to 
retrieve the information. 
Implementation Considerations 

a) Is e-mail likely to contain sensitive infonmation? 
When setting up an e-mail system, it is important to 

consider the content that will be transferred using the system 
and to apply the appropriate security controls accordingly. 
Is communication outside the local environment neces- 
sary? 

Is remote access required? 

If so, a gateway will be required to manage communica- 
tion beyond the local environment. This will bring with it 
security implications, as the local environment will no 
longer be isolated. 

b) Do e-mail capabilities already exist at the development 
site? 

If adequate capabilities are already present at the devel- 
opment site, it may well be pmdent to take advantage of 
these capabilities. 
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Product Considerations 

a) Is e-mail to be supported on multiple platforms? 

The choice of which product to use may depend on the 
platforms upon which the system must run. 
5 b) How many people should the system support? 

Low-end e-mail solutions may be perfectly adequate for 
small development teams. 
Teamware (240) 

In a creative environment, it is vitally important that 
10 people are able to easily share ideas and information. 
Teamware provides the ability to capture and share infor- 
mation across a project through the use of common -access, 
structured databases. A good example of teamware is the 
Knowledge Xchange. Teamware may be used to share many 
15 different types of information, for example: 

Technical support requests 

Technical hints, which facilitate trouble -shooting 

Change requests 
20 Resource reservation (for example, meeting rooms) 

Standards and procedures 

Status reports/meeting minutes 

Project member availability 

Project events and milestones 

Functional and technical issues 

Suggestions 

Project methodology 

In order to guarantee the value of a teamware 
^0 environment, it is vital that: 
Consistency is maintained 
Relevant updates are made (including deletions) 
Storage is not abused 
35 Security is enforced 

To ensure that information is consistent across different 
formats, it is useful to view the management of all these 
information sources as part of a more general information 
management process. Effective information management 
40 beyond repository management is required to ensure that the 
anticipated benefits of electronic mail and teamware mate- 
rialize. 

For example, certain teamware databases require continu- 
ous maintenance in order to remain relevant. The manage- 
45 meat of the database contents may require significantly more 
work than either the initial installation of the tools or the 
technical support for the tools. This effort . is frequently 
underestimated. 

In addition to setting guidelines for general usage, the 
50 project must designate mail administrators and knowledge 
managers who are responsible for: 

Maintaining user accounts 

Maintaining security profiles 

Managing database contents 

Removing obsolete information 

Managing resource usage (for example, disk space) 
Implementation Considerations 
a) What size is the project team? 
60 Teamware will generally only be effective when used 
within large groups of people. Unless a critical mass of 
people is achieved and content is regularly added to the 
system, interest will soon dwindle, and the system will no 
longer be of any value. 
65 Group Scheduling (242) 

Group scheduling tools help to centrally manage the 
personal schedules of a group of people. This offers the 
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advantage of being able to coordinate events that require the Application sharing 

participation of a number of people automatically by check- Application sharing allows participants to see and control 

ing 'group availability' rather than checking with each the same application running on multiple PCs. In this way 

person individually. These tools may also be used to sched- they can simultaneously create and edit a single, commoa 
ule other resources such as meeting rooms and equipment. 5 gie. Application sharing may be combined with audio con- 

For the use of group scheduling tools to be successful, the fercnce 

personal schedules of each member of the group must Process Management (1006) 

always be oirrent This is the re^onsibility not only of the p^^^^ Management may be categorized into two areas: 

group scheduler, but also of the mdividuals mvolved. ^. , . . . 

AudioA^ideo Conference (244) ^*™P'^ process mtegration 248, which concerns the 

In an ideal world, all meetings would be conducted face ^^^P^^ integration of a sequence of tasks, according to 

to face. In reality, however, it is often the case that not all the ^ prescribed development methodology, 

individuals who are required to take part in a meeting are on Workflow management 250, which concerns more sophis- 

the same site. To overcome this problem, audio and video ticated situations where several complex processes 

conferencing tools allow many individuals in different loca- require the participation of multiple groups, 

tions to communicate simultaneously. Audio conferencing is !□ either situation, the aim of the process management 

not a new concept, but remains a valuable tool for conduct- tools is to enforce the correct sequencing of tasks and tools, 

ing meetings where the issues being discussed do not require Xask integration must be provided in accordance with the 

the support ofvisual aids. Video conferencing takes this one methodology and should provide direct support for the 

step ftirther allowing people to mteract both aurally and methodology. Effective task integration therefore reduces 

visually, making for a much richer method of communica- 20 ^^^^^ methodology. 

. ^ -1 • Simple Process Integration (248) 

Implementation Considerations c- 1 n 1 . *- .u c 

V f u u J * J r Simple Process Integration concerns the integration of a 

a) Is there enough bandwidth to support a video confercoc- 1- / i-.r. j-^, 

ine svstem? umited sequence of tasks, for an individual, according to a 

Adding bandwidth intensive applications such as audio, P'^^^ development methodology. For example, the 

video, and data coaferencing could have severe effects on ^""Stmctton process can be supported wilhm an mtcgrated 

the network infrastructure and this must be anticipated. This development environment tool by a menu with the foUowing 
type of implementation is also based on a number of 

different, emerging standards. The video conferencing sys- Generate module template 

tem should be designed with that fact in mind and provide 30 Generate windows and dialogs 

for some degree of interoperability between dissimilar sys- Edit code 

tems. For example, being able to connect a desktop-based Compile 

video conference user with a room-based video conference Liak 

user. 

b) Is video conferencine the right medium for the desired 

purpose? Generate testdata 

Mdeo conferencing is an advantage when one person Execute test with debug 

needs to see the other person's face, his or her reactions, read Execute test without debug 

body-language, build relationships, and so on. On the other Edit script 
hand, when communication is more technical, for example, 49 Compare results 

fixing a bug, collaborative design, document writing, or The sequencing of the menu items help to remind the 

presenting a demonstration, it is more critical to be able to programmer of the steps needed to complete the construc- 

see what the other person is seeing, or to be able to show tion of the program. 

information at hand. In this case, application sharing Going beyond mere sequential use of tools, real-time 
assumes greater importance. It is a common misconception 45 integration of tools enables real-time data interchange. The 

that video conferencing replaces working in the same place. most common example is perhaps the edit/compUe/debug 

The logistics involved in setting up a group video confer- cycle. Here it can be very helpful to work in an integrated 

ence for different time zones, and the complexity of sharing environment that uses the editor and places the cursor at the 

a common whiteboard, limit the value of the solution to position corresponding to a syntax error or to a given 
occasional sihiations. In a development environment, the 50 break-point defined to the debugger. This integration is 

real value of synchronous communication is not in being generaUy offered as a standard feature of an integrated 

able to sec someone else at the other end, it is in being able development environment. Task integration for the indi- 

to share a working session on a work object (see vidual can be achieved using scripting tools or a desk top 

Collaboration — Shared Workspace, below). manager. 

Shared Workspace (246) 55 Real-time tools integration is most commonly provided 

Shared workspace systems may be categorized as foUows: by vendors who deliver integrated environments. 

Electronic whileboarding Workflow Management (250) 

Application sharing When processes become complex and require the partici- 

Electronic whileboarding pation of multiple groups, simple integration techniques are 

An electronic whiteboard provides a large, clear screen 60 not adequate for managing the process flow. Workflow 
that can be viewed close up and at a wide angle, upon which Management tools address this problem by providing the 
participants may * write' with an infrared pen or a mouse. ability to define, manage, and execute automated business 
Images may also be pasted onto the whiteboard. Regular processes through an electronic representation of the 
workstations on a network may also be used for electronic process, both in terms of what has to be done, and by whom, 
white boarding, providing the appropriate software is 65 For any process where multiple groups are involved, well- 
installed. Electronic whileboarding often works in conjunc- defined procedures must be in place to ensure that work 
tion with video conferencing applications. flows from one task to another. Each participant must have 
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access to the information required to perforra the task, 
including the information from previous steps in the flow. 
This can be handled manually or supported by tools. If 
handled manually, it requires dedication, attention to detail, 
and significant training. 

Workflow Management can be applied to many processes 
within the development environment, such as quality 
assurance, migration, design/construction, system test, and 
standards development. 
Implementation Considerations 

Efficient tools support for Workflow Management 
requires standards and procedures that specify: 

Which tasks exist 

Expected and maximal duration of each task 

What the decision points are 

How the tasks fit together to form a workflow 

How work is routed depending on the nature of the 

case/issue 
Which roles exist 

Which roles can perform which tasks 
Which individuals can fiU which roles 
Priority of cases (for example, depending on the 

originator) 
Product Considerations 

Workflow Management tools must at a minimum provide 
support for 

Workflow definition 
Case Routing with 

Flexible assignment 

Escalation 

Exception handling 
Reporting 

Tools to assist Workflow Management should support the 
following: 

Specification of individuals, their roles and tasks, and 

their relationships 
Specification of the workflow 
Automatic routing of cases 

Exception handling if a task is not performed within a 

prescribed elapsed time 
Routing of a case based on its contents (for example, 
different decision processes depending on the impor- 
tance of the decisions) 
Assignment of cases to roles and to individuals, with 

manual override 
Assignment based on priority 
Re-assignment of cases 
Reporting 
Security Management (276) 

Security Management tools provide the components that 
make up the security layer of the final system, and may 
provide required security controls to the development envi- 
ronment. While some of these tools may be considered as 
nothing more than security-specific Packaged Components, 
many are an integral part of the development environment 
toolset. 

Security Management tools include: 

Intrusion detection — discovers and alerts administrators 
of intrusion attempts. 

Network assessment — ^performs scheduled and selective 
probes of the network's communication services, oper- 
ating systems, and routers in search of those vulner- 
abilities most often used by unscrupulous individuals to 
probe, investigate, and attack your network. 
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Platform security — minimizes the opportunities for 
intruders to compromise corporate systems by provid- 
ing additional operating system security features. 

Web-based access control — enables organizations to con- 
trol and manage user access to web based applications 
with restricted access. 

Fraud services — methods of verifying the identity of 
credit card users to reduce the amount of fraudulent 
credit card transactions. 

Mobile code security — protects corporate resources, com- 
puter files, confidential information, and corporate 
assets from possible mobile code attack. 

E-mail content filtering — allows organizations to define 
and enforce e-mail policies to ensure the appropriate 
email content. 

Application development security toolkits — allow pro- 
grammers to integrate privacy, authentication, and 
additional security features into applications by using a 
cryptography engine and toolkit. 

Encryption — provides confidential communications to 
prevent the disclosure of sensitive information as it 
travels over the network. This capability is essential for 
conducting business over an unsecured channel such as 
the Internet. 

Public key infrastructure — provides public-key encryp- 
tion and digital signature services. The purpose of a 
public-key infrastructure is to manage keys and certifi- 
cates. A PKI enables the use of encryption, digital 
signatures, and authentication services across a wide 
variety of applications. 

Authentication system — provides a business with the 
abihty to accurately know who they are conducting 
business with. 

Firewall — protects against theft, loss, or misuse of impor- 
tant data on the corporate network, as well as protection 
against attempted denial of service attacks. Firewalls 
may be used at various points in the network to enforce 
different security policies. 
Product Considerations 

a) Does the tool use Role -based access control? 
Role-based access control establishes access rights and 

profiles based on job functions within the environment. If 
different access rights are required for security administra- 
tors vs. code developers vs. code reviewers vs. testers, then 
the correct access can be established based on these func- 
tions. 

b) Does the tool have flexible auditing capabilities? 

The security administrator should be able to granularly 
configure what is being audited by the tool. The audit logs 
should be able to optionally record User ID, time-of-<lay, 
location of access, successful and unsuccessful access or 
change attempts, etc. 

c) What are the performance implications of the tool? 
Some security services, such as content scanning or 

auditing, may add noticeable processing time and require- 
ments to the system. Tools should be architectured in such 
a way that performance impacts are or can be configured to 
be minimal. 

d) Does the tool comply with industry accepted standards? 
Many standards are emerging in the security technology 

marketplace. These include standards for cryptographic 
services, directory services, IP security, etc. In order to 
enhance future integration possibilities, choose vendors who 
are developing open solutions which comply with standards 
Information Management (262) 

Information Management of the development architecture 
is provided through an integrated development repository. 
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At this level of integration, tools share a common repository A logical repository integrates multiple tools to form an 

of development objects, design documents, source code, test application development repository. The various tools 

plans and data. Ideally, the repository would be a single employed in the development environment are bridged 

database with an all-encompassing information model. together by custom architecmre components. This approach 

Realistically, the repository must be built by integrating the 5 is commonly used when the Engagement team takes a best 
repositories of the different development tools through inter- ^^^^^ approach to tool selection, 

faces. Tool vendors may also build part of the integrated c) What are the current and proposed future platforms? 
repository by integrating specific products. Engagement team should determine whether the 

Implementation Considerations . ^ ^ , repository must support multiple platforms. The selected 

a) Isthereadesiretoentorceconsistencym the development . , 1. u . 1 ^ * 1 *c ^ . 1 
^Q^^*) ^10 tool should not only support current platforms but also 

' Engagement teams should consider the use of a repository ^"PP°^^ ^'""'f P*"^^^"" ^^^^^ P^^j^/^;,. , 

to enforce consistency across development efforts. A reposi- ^) P^^^^' ^^PP«^^ "^^^^P^^ ^^^^^^^^ «f 

tory can store standard data, process, design, and develop- ^^^e repository should support multiple versions of 

ment objects for use during application development activi- objects. By doing this, the repository can support appUca- 

ties. Developers then use these standard objects during tions in multiple phases of development. The repository tool 

implementation. As objects are defined once in the reposi- should control access to the versions of objects by providing 

tory and reused throughout the implementation process, check-in and check-out functionality. This allows multiple 

applications display a consistent look, feel, and flow while developers in various phases of development to work from 

enforcing the standards inherent in the repository objects. the sanae repository while allowing only one developer 

b) Will analysis and design objects be reused? 20 update access to a particular object at a time. 

Based upon engagement experiences, an engagement e) Are there existing tools that influence the selection of the 

team should consider using a repository when the develop- Information Management tool? 

ment team reuses analysis and design objects and deliver- Engagement teams have found that tools used in other 

ables during later phases of the development process. A parts of the client organization influence the selection of a 

repository houses many application development compo- 25 repository tool. Clients may have experience and existing 

nents including data definitions, process models, page skills with certain Information Management tools that drive 

designs, window designs, common GUI widgets, message the decision to use those tools corporate-wide on other 

layouts, and copybooks. initiatives. The KX may also provide input to the tool 

These components can be reused across large develop- selection process based 00 previous experience and skills of 

ment projects to increase developer productivity and 30 team members. 

decrease the risks associated with coding and testing the f) What are the other capabilities of the tool? 

same components multiple times. Engagement teams often chose a tool that can be used in 

c) How large is the development team? other areas of the development environment. Many Engage- 
Large development teams require more standardization ment teams select data modeling tools that can double as 

and control in order to ensure that the team remains pro- 35 Information Management tools. Using one tool for multiple 

ductive and maximizes reuse of analysis and design com- purposes results in fewer integration points in the architec- 

ponents. A repository provides the development teams with ture and less time and cost training personnel on multiple 

the abihty to reuse objects defined in the repository in a tools. 

controlled manner. Most engagements consider using a g) Should the Information Management tool support mul- 

repository once the number of developers exceeds ten. 40 tiple repositories? 

d) Is the development team geographically dispersed? As many repositories do not provide sufiBcient versioning 
An Information Management repository is crucial when functionality, it is common to have more than one repository 

teams whose designs must integrate are in different places. on large projects. Typically there would be one repository 

The repository becomes a means of communication that is for development, one for system test, and one for produc- 

formal and enforces the agreed interfaces. 45 tion. This improves overall control. Another reason could be 

e) Do a number of tools need to be integrated? that there is concurrent development of different releases, 
A repository management tool may be required to provide each requiring its own repository. Hence, on a large project, 

an integration platform for existing and future tools, pro- a tool that supports multiple repositories is often a require- 

viding communication among all tools where appropriate. ment. 

Product Considerations so Does the Repository Management tool allow only autho- 

a) Is support for user defined objects required? rized changes to be made to its contents by providing some 
The repository may need to be extended by the Engage- form of access control? 

ment team to support custom objects defined by the Appli- Th& repository contents are effectively the building blocks 

cation Development team. Some repositories support user- of the system and have broad reuse. A facility for security is 

defined objects as part of the base functionality. Others aUow 55 required to prevent unauthorized changes to the repository 

customization of the repository by the user while some are elements and hence to ensure high quality and consistent 

not designed for customization at all. If the repository repository content. For example, restrictions are often placed 

requires extensive customization, a buy versus build deci- on making changes to data elements because ad- hoc changes 

sion may be required. by a single designer could have devastating impacts on other 

b) Is a logical or physical repository more beneficial? 60 parts of the design. Repository access control is important 
The Engagement team must consider the costs and ben- where developers in the development environment need to 

efits of a physical repository versus a logical repository. A be assigned different rights to the repository. Typically, the 

physical repository is implemented as a single product. developers will be placed in groups with diminishing access 

Many CASE tools employ this type of repository by housing rights such as repository administrator, technical support, 

all application development objects in a single source. 65 designer, or programmer. These access rights may relate to 

Application development tools are then tightly integrated read/write/modify/delete authority. This method of access 

with the repository. coptrol is far more flexible than simple object locking. 
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h) Does the toolprovide repository reporting facUities? 
Repository reports serve as an audit trail for changes to 

objects within a repository and can be used to communicate 
these changes to the entire team. The Repository Manage- 
ment tool should provide this utility. 5 

Reports for impact analysis are extremely useful in the 
change control process. As the repository maintains rela- 
tionships between repository objects, * where-used' and 
* contains' report facilities can be very useful when dealing 
with change requests. 

i) Is the tool an active or passive Information Management 
tool? 

Active Information Management tools can be used to 
generate components, whereas passive tools are used to hold 
information about the tool but are not used to build the 
system. The use of an active Information Management tool 
increases productivity because of the facility to generate 
components. 

Does the tool need to be customized to provide an integra- 
tion platform for all the tools in the current development 
environment as well as those to be supported in the future? 20 

If the repository needs to be customized in order to 
integrate with all the required tools, then it is important that 
the Repository tool has a published interface and underlying 
data model. Using such a repository makes interfacing other 
tools with the repository considerably easier and less time 25 
consuming. 

Flexibility is important if a number of point tools are to be 
used in the development process as opposed to using an 
integrated CASE tool. 

j) Does the tools repository support validation? 

All key characteristics of repository objects (for example, 
data elements) and their inter-relationships should be vali- 
dated. Taking data elements as an example, these character- 
istics may include: 

Naming standards for data element names 

Naming standards for variable names associated with 
each programming language 

Data element types 

Data element length and precision ^ 
Data element window display and internal precision. 
At a minimum, naming standards must be validated to 

allow better navigation of the repository and easier reuse of 

elements. 

Does the tool provide a means of describing entities, such as 45 
source code files that do not exist as repository objects? 

The integrity of references to entities that exist outside the 
repository but within the folder management system must be 
maintained. If the tool does not directly support this, pro- 
cedures will have to be put in place to ensure the consistency 
of references to these entities. 
Repository Management (202) 

Repository Management is the key information manage- 
ment tool. The repository should be: 

Open, with a published interface and an underlying data 55 
model. In some development environments multiple 
repositories may be used. One repository can be inte- 
grated to an upper-case design tool, and another one to 
a lower-case design tool, each of them oflfering the best 
capabilities in their respective domain. It is then key gQ 
that repositories offer import/export capabilities, so 
proper bridging/synchronizing capabilities can be 
developed. 

Extensible, affording the flexibility for extending the type 
of information that can be captured. 55 

Integrated, with the tools that are used to populate the 
repository and to draw information from the repository. 
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Scalable, the repository-enabled environment must be 
able to support tens to hundreds of users 
simultaneously, and tens to hundreds of thousands of 
repository relationships. It should also scale 
downwards, so that it can also be easily used by small 
projects. This is a major criteria for usability. 

A development repository results in three important ben- 
efits for a development organization and for the business 
units they support: 

Information is kept in one place, in a known and orga- 
nized structure. This means that effort is not wasted 
initially in recreating work that already exists and effort 
is not wasted later on when reconciling relevant infor- 
mation. This is often referred to as "full life-cycle 
support." 

Design information, created for one step of the develop- 
ment process, can be fed to the next step, reducing 
effort and knowledge "gaps" or misunderstandings. 

The repository captures information relevant to each stage 
in application development: design 1102, construction 
1104, testing 1106, migration, execution, and operation 
1108 

FIG. 11 is an illustration showing information captured in 
the Repository and reused. 

The challenge is to create such a repository. Most of the 
available tools on the market do not explicitly support this 
comprehensive concept of a repository. 

The alternative is to: 

Extend the repository. This is why the extensibility of the 
repository is so important. When extending the 
repository, consider how well future versions of the 
base repository will accommodate the extensions. 
Migrating to a fiiture version may be more difificult after 
extending the repository. Extending the repository 
therefore requires a careful trade-off. 
Use several repositories. It is not infrequent to see two 
repositories coexisting; for example, one upper-case 
and one lower-case repository. Bridges between these 
repositories are key. Quality of import/export capabili- 
ties of the various repositories are key. 
In many instances, content may not be stored directly in 
the repository and must be placed in storage. In this case, 
only a reference is stored in the repository. 

When complete integration is achieved, the repository can 
serve as a communication cnabler for a large collection of 
development tools, FIG. 12 is an illustration showing the 
Repository's central role in the development environment. 

This can be achieved either by using an integrated CASE 
tool, or by integrating point tools around a common reposi- 
tory. 

In addition to the repository, which plays a key role, other 
important tool categories include the following, 
k) Security 

Repository access can sometimes be controlled using an 
access control function, which comes with the repository. A 
common technique is to group users and assign different 
access rights to the different groups. Each of these groups is 
also assigned specific readAvrite/delete/modify authority. 
For example, the following groups may be defined as having 
increasing rights: 

Programmer 

Designer 

Technical support 
Repository administrator 

A less flexible alternative is to lock objects. A locked 
object cannot be changed until the repository administrator 
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unlocks it. This is a less flexible approach but may be used 
when flexible access control functionality is not part of the 
repository. A tricky, and somewhat risky, approach to com- 
pensate for lacking access control functionality is to use 
information about the repository's internal storage mecha- 5 
nism to design an access control scheme. For example, if 
data elements are stored in a particular directory, tools from 
the network operating system can be used to limit access to 
that directory. If data elements are stored in a particular 
table, tools from the DBMS can be used to limit rights to that jq 
table. How well this works depends on how gracefuUy the 
repository handles error messages from the network oper- 
ating system or the DBMS. This approach should be tested 
before it is implemented. 
1) Repository Maintenance 

Creating and Changing Data Elements — As soon as data 
element maintenance becomes structured and is based 
on formal requests, it is practical to make the requests 
available to the developers in electronic format. Ideally, 
the requests should be entered into a database, which 20 
also contains information on status, comments on the 
request, and other pertinent information. This database 
can be a useful communication vehicle. 
An alternative approach to maintaining history in cases 
where the repository does not offer good versioning 2s 
capabilities, is to maintain a shadow repository where pre- 
vious versions of repository objects are stored. This only 
works for those repository objects whose maintenance is 
strictly controlled. 

Creating and Changing Other Repository Objects — It 30 
often occurs that the repository is part of an integrated 
CASE tool. Here, the tools used to populate the reposi- 
tory come with the repository and the integration work 
is already complete. 
This, however, is not always the case. In some instances, 35 
the tools for populating extensions of the repository are not 
provided, and in other cases, a stand-alone repository is 
used. In these cases, the integration between the design tools 
and the repository must be performed by the Technology 
Infrastructure team. This was achieved on a number of 40 
projects that chose a "best-of -breed point tool" approach 
where they integrated these point tools around a repository. 
The integration may require some challenging work writing 
parsers, which analyze the output from the individual point 
tool, and use this to populate the repository. These technical 45 
complexities should be hidden from designers and program- 
mers by providing friendly interfaces to the parsers, or by 
having the repository administrator trigger the parsing at 
regular intervals. 

Repository Validation and Mass Changes — All key char- 50 
acteristics of data elements, and their inter- 
relationships, should be validated, including: 
Naming standards for the element name 
Naming standards for the variable name associated 

with each programming language ss 
Type (for example, numeric and alphanumeric) 
Length and precision 
Window display and internal precision 
Similar validation can be performed on other repository 
objects depending on project standards. At a minimum, 60 
naming standards must be validated. This helps designers 
navigate the repository and thereby encourages reuse. 

Import and export utilities, which provide exchanges 
between the repository and flat files, can be useful in several 
ways. They make it easy to take a snapshot of the repository 65 
for archiving, and they allow for reuse of the contents of 
other repositories. 
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m) Analysis, Reports, and Queries 

Reports for impact analysis are extremely useful in the 
change control process. As the repository maintains rela- 
tionships between repository objects, where-used and con- 
tains reports are usually provided with the repository. Stor- 
ing the names of affected repository objects in an area- 
affected table can be useful when grouping change requests 
during assignment, or when defining a release. The area- 
affected table is also a valuable tool that can be used to 
facilitate migration from development to system test. 

The ability to easily create various repository reports is 
important to leverage the information in the repository. A 
scripting language, a simple report builder, or a query tool 
provides this capability. Having a query tool with an intui- 
tive user interface and good report formatting feamres is a 
necessity on a large project. The query tool can be used to 
provide standard reports for designers and programmers, 
printed design information for external reviews, and ad hoc 
requests for the repository administrator 
Folder Management (204) 

It is not always practical to store all information in the 
same repository. One reason for this is the repository's 
physical implementation. For example, if the repository is 
implemented on top of a relational DBMS, this supporting 
structure does not provide good support for storing flat files. 
It may therefore often be most practical to populate the 
repository with place-holders for entities which reside out- 
side the repository. With this scheme, the place-holder 
serves as a logical pointer. This scheme obviously requires 
some work to ensure integrity, but in practice it can work 
quite well. It works better if the objects outside can be 
organized in a structured way. This is where folders come in. 
They can be used to impose a structure on flat files; a 
stmcture, which can correspond to the strucmre of the 
repository. Folders should provide: 

Flexible access rights based on user profiles, which dif- 
ferentiate (at least) between read and write access 

Efficient search for a component across several folders 

Migration between folders 

Nested folders 

Links to avoid duplication of components while still 
showing that a component belongs to several folders 
Media Content Management (206) 

Methods for storing and managing media content range 
from simple folder management techniques to multimedia 
digital asset management systems, capable of indexing and 
manipulating numerous multimedia data types. There are a 
number of key requirements for Media Content 
Management — in particular, a Media Content Management 
system should have the abiUty to: 
Manage multiple file formats 
Efficiently store high volume files 
Manage metadata on files within the system 
Manage multiple versions of media files 
Manage revision history of changes to media files 
Control media storage across locations (online, near line, 
offline) 

Whether the functionality described above is handled as 
an integral part of the system, or by manual processes 
implemented by the Information Management team depends 
on the richness of functionality provided by the tools chosen. 

Additional functionality provided by advanced Media 
Content Management tools may include: 

IntelUgent indexing of media types (allowing specialized 
search facilities) 
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Capabilities for browsing media content (low-res images, 
previews) 

High performance proprietary file systems (both in terms 
of speed and volume) 
Implementation Considerations 5 

a) What formats need to be supported? 

The method of Media Content Management depends 
heavily on what media is to be stored. Ensure that the target 
media formats are understood before implementing the 
Media Content Management approach. lO 

b) Where should media content be stored? 

Where to store media content greatly depends on the 
volume of media to be stored, and the performance require- 
ments for retrieving that data. One thing is certain however; 
when dealing with large quantities of media, it is necessary 15 
to employ a dedicated media server, thus avoiding volume 
and performance hits with the rest of the development 
environment, while allowing the possibility of tuning the 
media server for optimal performance. 

The cost of data storage is not insignificant, especially 20 
when considering the total cost (not just that of the hardware 
and software, but also the effort required to support it). This 
means that much thought must be put into a media storage 
strategy. This includes a strategy for deciding which media 
should be on-line (instantly accessible), near-line (accessible 25 
with short delay, for example, CD juke box), or even 
possibly off-line (manual intervention required). 
Object Management (208) 

Object Management tools provide capabilities for view- 
ing objects, their methods and attributes, and the dependen- 30 
cies between these objects. 

Object Management tools also provide specific analysis 
tools, in order to understand inlerdependencies between the 
core classes and the components. When classes and com- 
ponents are modified, impact analysis tools are required to 35 
see where the modified entity is being used, allowing them 
to understand what is the overall impact of the change. This 
is more complex than with traditional systems as a veritable 
spider's web of dependencies between classes, components, 
and applications may ensue. In addition, OM features such 40 
as inheritance and polymorphism make tracking down 
dependencies with simple text search tools much more 
diflBcult. 

Quality Management (264) 

Quality Management is a management discipline that 45 
promotes a customer satisfaction focus and continuous 
improvement. Quality Management tools support the defi- 
nition and implementation of quality. 

A number of integrated Quality Management tools are 
available that may combine the functionality of all the 50 
required quality subcomponents into a single product. Many 
quality processes however, (such as Expectation 
Management) do not require specialized tools, and are 
therefore supported by standard productivity tools. 
Metrics (210) 55 

Metrics are an important part of quality management in 
that they provide a method of measuring (for example, 
sampling, testing, and determining) whether a process or 
product meets a given criterion. With Metrics, different 
stakeholders can agree that a product objectively meets an 60 
expectation, or that a process has been improved by a 
measurable amount. Without Metrics, stakeholders can only 
have subjective opinions that may or may not agree. 

Measurement tools are used to measure process quality 
and product quality. Process quality may include Metrics 65 
such as the time it takes to process a change request. Product 
quality should be measured for all the product expectations 
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the project has set. This measurement process is the inspec- 
tion part of quality management. 
Statistical Process Control (252) 

Statistical Process Control tools are used to analyze the 
results obtained with the measurement tools. These display 
trends that can be used as the basis for process improvement 
or, in other cases, product rework. 
Continuous Improvement (212) 

Continuous Improvement tools are used to analyze and 
improve the development processes. 

Continuous Improvement is a process management tech- 
nique by which action is taken to modify a process when the 
measurement or outcomes of that process are unsatisfactory. 
Process improvement is required whenever the number of 
defects exceeds the desired level, productivity falls below a 
desired threshold, or cUent expectations fail to be met. Once 
the process has been modified, it is remeasured to see 
whether the expected gain was actually achieved. 
Training (254) 

Training tools provide methods to apply a standardized 
Gaining approach to a large group of people. Training tools 
can complement or take the place of traditional instructor- 
led training depending on the type of information that must 
be communicated. Computer-Based Training (CBT) tools 
offer the advantage of being able to train personnel direcdy 
on the target environment. 

At the more basic level, training tools can also include 
online or paper-based training materials — not offering all the 
advantages of CBTs, but still providing the flexibility and 
convenience because they can be conducted as and when the 
trainee requires, and in any location. This removes the need 
to organize classes. 

The decision of whether to use CBT, online, paper-based 
or instructor-led training is affected by the number of people 
that have to be trained, the complexity of the subject, and the 
availability and distribution of the people to be trained. 
Program & Project Management (274) 

Program and Project Management tools assist the man- 
agement teams in their daily work. These tools, typically 
packaged as integrated suites of software, provide the basic 
functionality required for planning, scheduling, tracking, 
and reporting at both the program and project level. 
Planning 

Planning tools are used to assist in program and project 
planning including the development of the Program 
Resource Plan, the Work Breakdown Structure (WBS), the 
Organization Breakdown Structure, Cost Accounting, 
milestones, and deliverables. 
Scheduling 

Scheduling Tools are used to allocate resources against 
the WBS, to determine the timeline for a specific project, 
and to schedule the allocation of resources at the program 
level. 
Tracking 

Project tracking tools enable the project manager to track 
the actual project status against the original plan and sched- 
ule. Integration with the time reporting system and tech- 
niques such as Estimates to Complete (ETCs) are valuable 
in tracking project status. 
Reporting 

Reporting Tools are used to summarize status and metrics 
to program and project management. 
Configuration Management (270) 

Configuration Management tools ensure that consistency 
between components and a given envirotunent is maintained 
over time as components are changed. 
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Implementation Considerations 

a) Does the testing effort involve numerous applications 
with common components? 

Engagement teams frequently require Configuration Man- 
agement tools to support the testing process. Large devel- 
opment efforts may have multiple releases of an application 
in the development pipeline (development, unit test, inte- 
gration test, user acceptance test, and production). 
Additionally, some environments have multiple appUcations 
that share common components. Multiple versions of com- 
mon components may be required depending upon the 
application being tested. Configuration Management tools 
assist in migrating code between these environments. These 
tools can also be used to manage different versions of test 
scripts for various releases of an application. 

b) Where is the development team located? 
Configuration Management tools are essential when 

development teams are not centrahzed at one location. These 
tools provide services, such as version control, when geo- 
graphically distributed teams need to access common mod- 
ules or data, such as code tables. Configuration Management 
tools may still be necessary even if the development team is 
centralized, depending upon other criteria such as develop- 
ment team size. 

c) How large is the application or development team? 
Large applications, as well as large development teams, 

require Configuration Management tools to help control 
versioning of code, changes to code, and migration of code 
(and accompanying design and test documentation) through 
the development and testing environments. 

As the size of the team increases, the communication 
between team members becomes more cumbersome. The 
Configuration Management tools provide a structure for 
communication between team members regarding version 
control, change control, and migration control. 

As the size of the application increases so does the 
number of objects, files, or components. The management of 
these items becomes increasingly difficult to manage and 
track during the development process. The Configuration 
Management tool provides structure for managing the 
objects, files, and components and reduces the risk of lost 
information caused by version problems, or by items not 
being migrated properly. 

d) Is the development effort to be sustained over a prolonged 
period? 

Over time, a large number of configurations will evolve 
and Configuration Management tools can be used to control 
the evolution and to document these configurations. 

e) Is there a large number of components? 

It may be necessary to keep track of and control configu- 
rations consisting of objects such as training materials, 
documentation, hardware components, system software and 
even building characteristics. The existence of a large num- 
ber of such components makes the task of managing their 
configurations complex, and a dedicated Configuration 
Management tool becomes crucial to the process. 

f) Are multiple organizations contributing? 
Configuration Management tools arc particularly impor- 
tant when there are multiple vendors and subcontractors 
involved and there is a need to align what is assembled in 
preparation for the integration test. 

g) Does the system exceed 100 modules? 
Configuration Management tools are needed once the 

system becomes large and many modules (which may 
include programs, header files, copybooks, shared 
components, subroutines, and so on) have to be managed. 
There is a significant cost involved in formal configuration 
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management. If the system has a little over 100 modules, the 
Configuration Management component may consist merely 
of a whiteboard or Excel spreadsheet. As the number of 
modules grows to about 1000, a dedicated tool is required. 
5 h) Do the generations or versions of components change 
frequently? 

A Configuration Management tool is important if many 
generations or versions are to be managed. This will gen- 
erally be the case if the project involves a large development 

10 team. There may be external factors that the project team has 
no control over such as hardware vendors who change their 
configurations frequently. The internal components, for 
example, software modules must be configured to match 
external components such as operating systems and hard- 

15 ware components. 
Product Considerations 

a) Should the engagement team buUd a custom configuration 
management tool or purchase an existing one? 

An engagement team must determine whether to purchase 

20 a Configuration Management tool or build one. The build 
decision should consider the cost of designing and devel- 
oping the fiinctions required by the engagement team. 
Additionally, the projea must consider the resources and 
development time required to build the tool and when the 

25 tool is needed in the application development schedule. 
The buy decision can still be expensive and requires 
additional investments for training project personnel. These 
tools also provide many features that may not be required by 
the engagement team. 

30 b) Does the engagement team have more experience with 
certain tools? 

Engagement teams found that tools used in other parts of 
the client organization influence the selection process. 
Teams may have experience and existing skills with certain 

35 Configuration Management tools that drive the decision to 
use those tools on other initiatives corporate-wide. One may 
also provide input to the tool selection process based upon 
previous experience and skills of team members. Using tools 
that the engagement team already has experience with 

40 provides several advantages, especially a reduction in train- 
ing costs. 

c) Does an existing component satisfy this requirement? 
Engagement teams sometimes choose tools that provide 

multiple development functions, including Configuration 
45 Management tools. The decision to choose between avail- 
able Configuration Management tools may already have 
been decided as a result of using certain other tools within 
the development environment. 

d) Does the product integrate with the existing or proposed 
50 architecture? 

The engagement team should select tools that integrate 
with other tools in the development environment and operate 
on the same platform. Project teams should select tools 
where vendors provide support for the integration between 

55 the Application Development tool and the Configuration 
Management tool. Such integration helps to easily and 
effectively manage the objects or files created by the Appli- 
cation Development tool. 
How does the project define a configuration? 

60 Does the tool handle aU types of components in the con- 
figuration? 

The components involved in Configuration Management 
typically involve hardware, system software, and applica- 
tion components together with their documentation. The 
65 tools should be able to manage and keep track of all the 
component types that make up a configuration. 

e) Does the tool provide capabihties for exception reports? 
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If for some reason a repository component is not at the d) Is it likely that the system will need to be rolled back to 

correct promotion level, the tool should be able to report on a previous version at some stage in the development? 

this when required. This is typically the case when the project is breaking 

£) Will a source control system sufiSce as a Configuration ground, using new techniques or untried architectures. Ver- 

Management tool? 5 sion Control tools provide a means of taking snapshots of the 

Generally, source control systems must be enhanced to system in time. If there are changes in the environment that 

provide a basic Configuration Management tool. The fuoc- force the system to be rolled back to a previous stage in the 

tional enhancements are typically: development, Version Control tools allow access to previous 

Definition of a grouping mechanism for files to associate versions and mechanisms for reverting to an earlier version, 

them with certain versions. lo When should I set up version control? 

Promotion mechanisms Version Control should be set up from the beginning. By 

Definition of interconfiguration dependencies such as delaying version control, manual Version Control must be 

between a particular version's files and that version's "^ed. This result can be an increased cost in disk space in the 

related test data. development environment (because of the number of ver- 

g) Does the toolprovide ease of access to information? 15 ^^^^ ^^^^ "i^"^^ ^^^^ ^^^^ ^ *^^P0 and can lead to some 

The tools should automate the storage and retrieval of aU hmnan versioning errors, 

dependent software components indicated by an impact 0 What kind of information should I add to version control? 

analysis report. There are different approaches: Everything (hand-made 

Version Control (214) code, generated files, documentation, even compiled exec 

Version Control tools control access to source code as it 20 DLLs), some of the above etc. In general, documeo- 

is developed and tested and allow multiple versions to be ^^o" should be added if no additional design repository 

created, maintained, or retrieved. For example, a source ^^^ts, otherwise, use the repository, which usuaUy has a 

code comparator can be used to idemify changes between versioning capability. Adding bmary files will usuaUy have 

different versions of programs. ^ ^ considered dtuing the initial setup phase, as this 

The component-based development raises a new chaL 25 squires significantly more memory and not all tools can 

lenge: when a single component is used by several handle binary files in a correct manner 

applications, versioning becomes significantly more com- Which stages to add? 

plex and therefore, advanced versioning software, including stages in the version control (Dev, Assembly test, 

system support for versioning, is required. system test, etc.) should be added according to the devel- 

Implementation Considerations 30 opment approach. Strong relationship to migration control. 

a) Should the evolution of the system be tracked in terms of Should also be automated and is usuaUy supported by the 
who makes changes or why certain decisions are made along tools. 

the way? Product Considerations 

Version Control tools allow systematic storage of infor- ^) ^ool provide capabilities to cater for a system 

mation about who makes changes in what order so that the 35 ruaniog on multiple platforms or a distributed system? 

evolution of the system can be tracked. The tools usuaUy IdeaUy, the Version Control tool must be able to operate 

provide a facility to report on differences in versions so the 0° platforms in use, whilst at the same time perform- 

version that existed when a critical change was made can be Version Control for aU components across the entire 

identified and recreated or retrieved. The tools can also system. 

provide a means of documenting why decisions are made 40 b) Does the tool provide support for actions like mass 

during the evolution of the system. These decisions would builds? 

have been made based on the version of the documentation Usually, custom tools are put on top of the vendors tools 

for the system that existed at that time. Version Control tools ^ support actions like mass builds etc. Some tools (or 

aUow the state of the system at a particular time to be add-ons) support this already. This is vital for the project, as 

recorded. Hence improved auditabUity for decisions can be 45 ^^^^ws huge productivity gains in later phases of the 

achieved. project. 

b) Is there a~ large development team? ^5°^ ^^^X implement batch solutions? 
Version Control tools allow developers to work semi- . should be considered if a batch/API interface exists for 

independently and to choose the degree of integration they implementing batch solutions, 

need at any given time. They can shield themselves from the 50 Change Control (218) 

tentative development performed on shared components and Change Control system should provide the foUowing 

test a portion of the system with a stable environment around features: 

them. This prevents the development team from having to ^^^^ format description of changes 

develop one fuU sequence at a time and increases the ability Classification of changes in several different ways (area 

of a large number of people to work productively together, 55 affected, priority, estimated cost, authorization) 

thus compressing the time required to develop a system. Flexible, customizable sorting and reporting to ensure that 

c) Is there concurrent development of multiple versions of a change is handled in a timely manner 

the system? IdeaUy, the Change Control system should also be inte- 

A comprehensive Version Control tool set is critical if grated with workflow support, the repository, and the source 

there is concurrent development of multiple versions of the 60 code control system. This ensures rapid processing of the 

system. This is often the case when system development is change, accurate analysis of the area affected, and correct 

to be sustained over an extended period. Special provisions locking and unlocking of repository objects and source 

must be made to ensure that the library and repository modules, 

structures are rich enough to be able to support the necessary Implementation Considerations 

versions. In this environment, a log of changes also becomes 65 a) Does the project require strict scope control? 

very important as fixes applied to earlier versions generaUy Specifications and scope may be changed at any time if 

have to be applied to later versions as weU, Change Control tools and standards are not implemented. 
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This can result in the project running over budget, or being Flexible, customized sorting and reporting based on this 

delivered late with inconsistent quality because require- classification is required to ensure that change is handled in 

ments change continuously. a timely manner. 

b) Is the system complex? b) Should an Impact Analysis tool be purchased or devel- 
Change control has broader applicability than to just 5 oped? 

application source code. It may also afifect the look and feel. Impact analysis tools are. typically required to provide 

training materials, documentation, and so forth. Change analysis of a wide range of types of documents such as 

Control must be formalized if the system is complex with Word, Excel, or PowerPoint. 

many components. If an impact analysis tool cannot be found that supports 

c) Do changes need to be authorized by specific personnel? lO the entire environment, it is critical to develop procedures or 
Change control tools provide a vehicle for ensuring that utilities that will report on where items are used. The first 

only authorized changes are made and signed off. This step is to identify the items to be searched, and to build 

ensures conceptual, proper ownership of the total look and procedures around searching them (for example, databases, 

feel of the application. Change requests may also be rejected files, workspaces, programs, screens/forms, reports). It is 

or deferred by an authorized person. 15 also important to identify who will be responsible for the 

d) Is coordination of changes required? impact analysis (DBA, analysts, programmers, team leaders. 
Facilities to track interdependencies between change and so on) to avoid this work falling between the cracks. 

requests (for example, change request A must be completed c) Does the tool provide free format description of changes? 
before change request B can start) are provided by Change Free format descriptions are important because this allows 

Control tools. This can be used to encourage efficient 20 better and more understandable docxmientation of change 

scheduling and to ensiu-e that work is not duplicated, requests and associated decisions. 

e) Should a record be kept of changes that fall beyond the d) Are there going to be multiple releases of the software? 
capacity of the project at that time? The tool should allocate change requests to different 

Change Control tools can provide a vehicle for capturing releases based on priority and resource ava Liability. It should 

good ideas. If the project does not have the capacity to 25 also provide a means of attaching a deadline to a change 

implement those ideas at present, the Change Control tool request. 

can be used to capture those ideas. These ideas can be Does the tool provide a means of indicating which devcl- 

reinvestigated when a future release is planned- opment team member is best suited to perform the imple- 

£) Are conflicting change requests likely to occur? mentation of that change request? 

Change request tools can be used to identify changes that 30 This fiinctionality should be available as part of the 

conflict, for example, one user wants a green background scheduling capability. An added feature would be the capa- 

and another wants a blue background. The changes must bility to balance workload across the team, 

be-resolved through some kind of dialog or discussion and e) How does the tool handle exceptions? 
Change Control can be used to initiate this process. The tool should provide a capability to generate exception 

g) Is it likely that the system will need to be rolled back to 35 reports that highlight issues such as change requests that are 
a certain state? in danger of not meeting the release to which it was 

This is typically the case when the project is breaking allocated, 

ground by using new techniques or untried architectures. f) What is the prediction for volume of change requests for 

Change control tools provide a means of identifying at the project? 
what point in time a critical change was implemented and 40 The tool should be able to cope with the expected volume 

that information can be used to find out what version existed of change. 

at that time. g) Is validation of data entered into the change request form 

h) Is there a need to evaluate the impact of implementing a a consideration? 

change on the project ? It may be necessary to ensure that the data entered on a 

Change condrol tools typically support some kind of 45 change request form is valid. This is particularly important 

impact analysis and may be integrated with an impact if the development team is inexperienced or if the project is 

analysis tool set. Impact analysis is important in order to particularly complex. An example of data validation would 

group changes so that they can be implemented effectively. be to ensure that the change is assigned to a valid team to 

Multiple changes may afifect the same component and it prevent a change request from falling through the cracks, 

would be wasteful to open that component many times over 50 h) Is recording of resolution details and root causes 

and implement the changes one at a time. Impact analysis required? 

can be used to ensure that all relevant changes to that This capability provides useful tracking across the com- 

component are implemented together. Hence impact analy- plete life cycle of a change request, 

sis is important for scheduling purposes and for estimating i) What reporting capabilities are needed on the project? 
cost. 55 Some Change Control tools can report on status of change 

Product Considerations requests at the individual, team, and project level. Such 

a) Does the tool provide a capability to classify change reports can provide information about work done to date and 

requests? . Estimate to Complete (ETC) values. 

Change requests may occur as a consequence of changing j) How many users will simultaneously be accessing the 

requirements, or as a result of nonconformities (or defects) 60 system? 

in the system. The tool should be able to classify change The tool should cater to the size of the project. Maintain- 

requests into categories such as incidents, faults, or enhance- ing consistency of information may otherwise become a 

ments. The tool should also have the ability to update these problem with simultaneous access. The tool should provide 

categories if required. Qassification of different change some kind of protection of change requests if simultaneous 

requests in several different ways such as area affected, 65 access is likely to occur, 

priority, estimated cost or authorization is important to k) Does the tool provide a means of prioritizing change 

ensure correct scheduling of the implementation of changes. requests? 
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The tool should provide capabilities for prioritizing 
change requests based on business impact and the impact of 
implementiDg the change. 

Does the tool provide capabilities for predicting the cost, 
risk, and instabilities created as a result of implementing a 5 
change request? 

These capabilities need not provide completely automated 
prediction but should work in conjunction with an analyst. 
1) Does the tool identify component dependencies? 

This is an important aspect of impact analysis that is lO 
required to ensure that all components impacted by a change 
request are identified. 
Migation Control (216) 

Migration Control tools control multiple versions of 
source code, data, and other items as they are changed, 15 
tested, and moved from one development environment into 
another, for example, from development to test and firom test 
to production. Data migration control tools manage multiple 
versions of the database and its data to ensure that accurate 
data and structure are maintained in the environment, and to 20 
ensure that versions of application code and database are 
deployed consistently. Types of data that would be migrated 
include base codes data and converted data. Other Migration 
Control tools manage other types of objects to ensure that 
complete versions of all components reside in the production 25 
environment (for example, test definitions and scripts). 
Implementation Considerations 

a) Are there multiple environments running in parallel? 
Multiple environments are typically required when the 

project is faced with serious time constraints. Typically the 30 
project team performs integration or systems testing on one 
portion of the system, while developing the next portion. 
The team corrects errors based on one test while at the same 
time, the next lest cycle or testing of the next part of the 
system is performed. This means that multiple environments 35 
exist that are configured differently and use a different 
version of the system components. The migration of these 
different versions and configurations between environments 
must be carefully controlled using Migration Control tools. 
For successful migration there must be consistent migration 40 
of all components and their dependents. 

b) Are multiple releases being developed in parallel? 

If multiple releases are being developed in parallel, it is 
vital to provide a consistent means of migrating configura- 
tions and versions from one environment to the next. This 45 
ensures that there is no confusion of components in each 
release as the move is made from, for example, a unit test 
environment to a system test environment. 

c) Is the development effort to be sustained over a prolonged 
period? so 

Migration control tools keep a log of what is migrated. It 
may be required to review what has happened over time, in 
order to gain an understanding of the current status of the 
system. 

d) Is there a need to control who activates migration from 55 
one environment to the next? 

Migration control tools ensure that only authorized per- 
sonnel can trigger the migration of components from one 
environment to the next. 

e) Is the system complex (consisting of more than 1000 60 
components)? 

The task of promoting components and locking these 
components to prevent concurrent or unauthorized updates 
to them or their dependents becomes very intricate as the 
number of components reaches 1000. Migration control 65 
tools can be used to improve productivity by facilitating and 
controlling the migration from one environment to another 
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and by automating the process. It is possible to bring a large 
project to a complete halt if Migration Control is not 
properly enforced. 
Product Considerations 

a) Does the tool support the migration of all the components 
that make up a migration object? 

The Migration Control tool should be able to manage and 
control the migration of all the components (for example, 
source code, database access, make files, run-time data, 
environment variables, code libraries, code tables, third - 
party software, and so forth) which make up the object to be 
migrated. The complexity of the Netcentric world with so 
many integrated vendor solutions dramatically increases the 
number and variations of object types. 

b) Does the tool facilitate the migration of many components 
together as well as migrating components individually? 

Migration from a development environment to a system 
test environment either involves a large number of compo- 
nents (migration of all the components belonging to a test 
cycle) or single components (after code fixing in a program). 
Either way the Migration Control tool should lock the 
migrated component to control changes and allow better 
coordination with the system test team. 

c) Does the tool support all the required platforms? 

In a development environment where there may be dif- 
ferent platforms, it is important that the Migration Control 
tools be able to synchronize source migration across plat- 
forms. Unit and system tests are normally performed on 
every platform so the migration tool should be able to 
promote the components across platforms as well as from 
environment to environment. 

d) What is the migration strategy? 

A push strategy should be facilitated by the migration tool 
if it is decided that modules should be tested when those 
modules are ready for testing. This is normally the case for 
unit testing. A pull strategy is needed if the order of 
component testing is important as is normally the case for 
system testing. In implementing a push strategy it is usual 
for the individual programmer to be responsible for migrat- 
ing the module. If this is the case then the tool should be easy 
to learn and use. Using a pull strategy may decrease the 
number of people required to know how to use the tool. 
Release Management 

Release Management tools should provide: 

Planning functionalities, to help planning design and 
development effort 

Monitoring functionalities, in order to measure progress 
towards delivery goals 

Project interdependencies management 

Interface with the change control system 

Ideally, the Release Management system should also be 
integrated with workflow support, the repository, and the 
project/program management system. 
Environment Management (266) 

The modem development environment is both complex 
and sophisticated. It supports many different functional and 
technical requirements (illustrated by the execution 
architecture), many different development teams, tools from 
many different product vendors, and often must support 
projects at different stages of the development life cycle. As 
such, it is a mission-critical production environment and 
must be managed based upon an operations architecture. The 
extent to which the areas of the operations architecture are 
implemented must also be a factor of project size and 
duration. 

The environment management requirements in this sec- 
tion are based upon the MODE (Management of Distributed 
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Environments) conceptual framework. This section uses Archiving 

MODE as a framework, adopts MODE terminology, and Archiving can be particularly useful to safeguard infor- 

focuses on those management tasks from MODE which are mation from previous versions or releases. More generally, 

particularly important in the development architecmre. it is used to create a copy of information that is less 

MODE identifies four main areas: 5 time-critical than the current environmem at a given time. 

Archiving may be performed to a medimn, which is different 

Service Management backup medium, and may involve other tools 

Systems Management which, for example, provide a higher compression ratio. 

Managing Change Security 

Service Planning lo Security tools are required in the development environ- 

The subcomponents of Environment management reflect "^J^ ensure against unauthorized access by individuals 

*u c \Ar\T\r and system processes, to limit damages caused by such 

these four MODE areas. • j j * j * .i. ■ 

S Ma a ement (222) unauthorized access, and to audit access the environment 

^ \ ^. , c services. At the security management level, it may be 

Service Management took support the various aspects of ^^^^^^^ ^^^^ ^^^^ ^^^^ help manage security profiles, 

supporting and managing the mterface with developers. 15 security groups, and access rights. 

As defined in MODE, these include the foUowing: Product Considerations 

Tools to support and manage the Help Desk a) Does the tool use Role -based access control? 

Tools to support the creation, management, and reporting Role-based access control establishes access rights and 

of Service Level Agreements (SLAs) and Operations Profiles based on job functions withm the environment. If 

Level Agreements (OLAs) different access rights are required for security administra- 

r L J tors vs. code developers vs. code reviewers vs. testers, then 

Tools to manage and support the quality of the develop- ^^^^^^^ established based on these func- 

ment environment tions. 

Systems Management (226) b) Does the tool have flexible auditing capabUities? 

Systems Management Tools support and manage the The security administrator should be able to granularly 

operation of the distributed system. configure what is being audited by the tool. The audit logs 

Startup & Shutdown should be able to optionally record User ID, time-of-day, 

A comprehensive development environment rapidly location of access, successful and unsuccessful access or 

becomes sufficiently complex that the startup and shutdown change attempts, etc. 

of the environment must be managed carefully, and prefer- c) What are the perfonnance implications of the tool? 

ably automated. This is key to ensuring the integrity of the Some security services, such as content scanning or 

environment. Startup may involve the carefully sequenced auditing, may add noticeable processing time and require- 

initiahzalion of networking software, databases, web servers ments to the system. Tools should be architectured in such 

and more. Similarly, shutdown involves saving configura- a way that performance impacts are or can be configured to 

tion changes as needed and gracefully taking down running 35 be minimal, 

software in the correct sequence. Performance Monitoring 

Backup & Restore Performance Monitoring tools help ensure that the avail- 

The incremental value of the daQy work performed on the able resources are sufBcient to meet the developers' perfor- 

development project is high. This investment must be pro- mance requirements. These tools can be used to assess 

tected from problems arising from hardware and software 40 end-to-end perfonnance of both batch processes such as 

failure, and from erroneous user actions and catastrophes backups, and uiteradive processes such as repository-based 

such as fires or floods. The repositories and other develop- retrieval, 

ment information must therefore be backed up regulariy. Service Planning (224) 

Backup and restore procedures and tools must be tested to Service Planning is the planmng required to anticipate and 

ensure that system components can be recovered as antici- 45 implement changes to the following areas: 

pated. The large volumes of complex data generaUy require Service management 

automation of backups and restores. Systems management 

The advent of Netcentric technologies has introduced an Managing change 

increase in media content that requires storage (see Strategic planning 

Processes — Information Management — Media Content 50 All these areas relate to the development environment and 

Management). The environment may support a high volume are analogous to the kind of planning that must occur in the 

of media files, which must be considered in the backup/ business application's production environment. Key types of 

restore plans. Storage capacity planning should allow for the tools for development environments include Performance 

typically increased size of these file types. Modeling and Capacity Planning tools. 

As the amount of storage will grow significantly over time 55 Performance Modeling 

on a large project, the hardware requirements will increase. Performance modeling tools in this category support the 

Sufficient room for growth should be planned when select- analysts of the development environment's performance, as 

ing the tools and hardware. Switching tools and hardware opposed to that of the client/server application being devel- 

can be problematic due to lack of upward compatibility oped, A simple spreadsheet may be suitable in some well- 

(DDS — DLT, various tools etc.). 60 known and understood environments, but dedicated perfor- 

The time required for backups must also be considered. ma nee modeling tools should be considered on any project 

Usually the number of hours without development per day with high transaction volumes or complex environments 

decreases over time and if backups can only be performed involving multiple platforms, 

when no user is logged in, this might become a problem. It Capacity Modeling 

is generally the case that the project will benefit from buying 65 Capacity modeling tools support the maintenance of 

the fastest and largest backup hardware/software it can adequate processing capacity for the development environ- 

afford. ment (for example, workstations, servers, storage devices. 
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and network capacity). These tools range from spreadsheets 
to dedicated capacity modeling and simulation tools. 
Managing Change (220) 

Managing Change tools support the various aspects of 
identifying and managing change in the development envi- 5 
ronment. Specific tools are discussed in detail in the MODE 
Products Database on the Knowledge Xchange. 

Data and Software Distribution is a key tool in this 
category for development environments that have several 
developers. These tools enable automated distribution of 
data and software to the workstations and servers in the 
development environment. 
Problem Management (272) 

Problem Management tools help track each system inves- 
tigation request — from detection and documentation to reso- 
lution (for example. Problem Tracking, Impact Analysis, 
Statistical Analysis), 

Problem Management tools log information about prob- 
lems detected, classify them, and generate reports. This is 
essential for capturing metrics information. 

The major fimctions of Problem Management are: 

Problem source and metrics information 

Problem solution information 

Planning support for problem fixing and migration prepa- 
ration 25 
Impact analysis capability: 

Link to the application design repository to get a 

precise impact analysis on a problem 
Link to the test plan management system to keep track 
of the cycle and test the condition where the problem 30 
occurred, to determine the test stage work unit 
affected by the problem 
It is important to select an automated Problem Manage- 
ment system that is integrated with the program's testing and 
Configuration Management tools. Therefore, the Problem 35 
Management system must be able to support the testing 
model selected, for example, the V-model, and have tight 
integration with the Migration and Version Control tools 
associated with Configuration Management. 

An automated test script tool can be integrated to allow 40 
users to reference scripts that were being used when the error 
or defect was found. A data repository can be integrated into 
the Problem Management application that will allow the 
users to build relationships between problems and design 
and test documentation and application components. 45 

An ability to associate problems with affected work 
packages and a mechanism for version control changes for 
the work package is necessary so the package can be 
migrated back into the testing environment. 

When considering an automated tool, also consider what 50 
type of security is required for the Problem Management 
application. This is closely tied with the Configuration 
Management tools. Only one person should have the rights 
to review and approve problem analysis tasks as well as 
problem migration activities. 55 
Implementation Considerations 

a) How arc problems handled at each stage? 

b) How do I plan for trapping problems? 

c) Do I retest problems at different stages? 

The following is an overview stage containment as docu- 60 
mented by the Reinventing Testing Project (RTP). 

Stage containment is an approach to identify problems in 
the system before they pass to the next stage. It is a measure 
that helps build quality into the system. The goal of stage 
containment is to minimize the number of errors being 65 
passed to the next stage. For the purpose of stage 
containment, problems are sorted into categories. Errors are 



defined as problems found in the stage where they were 
created. Defects are problems found in a stage successive to 
the stage where they were created. Faults are problems 
found in production. The longer a defect remains 
undiscovered, the more difficult and expensive it will be to 
correct. Because each stage relies on the decisions made 
during the creation of the specification in the previous stage, 
detecting an error in a stage after it was made may invalidate 
some or all of the work done between the time the issue was 
created and the time it was discovered. 

The V-model specifies that testing in one stage must be 
completed before moving on to the next stage of testing. 
Before moving up to the next stage, it is key that the exit 
criteria defined for that stage have been met. A part of the 
exit criteria for each stage is that the test has been success- 
hilly executed, therefore ensuring the test objectives (or 
primary focus of the test) are accomplished before moving 
on to the next stage. 

Once the objectives of one test stage are met, there is no 
need to repeat the same testing at the next stage. This is a key 
concept of the V-model and one that proves difficult to 
accept and use in practice. There is often a desire to retest 
just to "make sure everything is OIC" Doing so, inevitably 
leads to time-consuming testing. In addition, it leaves less 
time to do the testing required for the current stage of testing, 
ultimately resulting in minimal, if any, time for the last stage 
of testing. In other words, minimize gaps and overlaps 
between the testing stages while ensuring quality of delivery. 

It is possible, however, that testing at one stage may, and 
should, use test scripts from previous stages. Two stages of 
testing may be executed together, using the same scripts, but 
both sets of test conditions must be covered (that is, both sets 
of objectives must be met). All stages of testing are required. 
For example, a thorough assembly test cannot make up for 
inadequate component testing, as the objectives of each test 
stage are different. 

d) What other components does the Problem Management 
system interface with? 

RTPhas identified the following components as interfaces 
with the Problem Management system. 

Configuration Management — When a defect is ready fior 
migration, the Migration Control system can be used to 
pass the Ust of components to migrate. The Problem 
Management system can keep track of the migration 
date obtained from the Migration Control system. 
Design Repository— An impact analysis of a specific 
component in error will be performed directly on the 
design repository by providing a means to use the 
appropriate design repository function or having the 
Problem Management system referencing the design 
repository objects. 
Test Data Management — ^Test results, expected results, 
and data comparison results can be linked to a defect to 
provide centralized access to the information. Integra- 
tion also aids in keeping track of the cycle where the 
problem occurred, the test condition, and therefore the 
business fiinction affected by the problem, 
c) How many design repositories should be used? 
f) What does the design repository interact with? 

Typically, the design repository represents the basis of the 
appUcation development. It is mainly involved during the 
construction phase of the application and is used to central- 
ize the application definition data. The design repository can 
be complex, providing impact analysis and application gen- 
eration features. 

In a testing environment, the design repository is a safe 
means of analyzing the impact of a problem on the whole 
appHcation. 
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Having two separated systems, one for Problem Manage- 
ment and one for application design, duplicates the infor- 
mation and introduces errors. Therefore, the interaction 
between the design repository and the Problem 
Management, Test Planning, and Configuration Manage- 
ment components significantly increases productivity and 
reduces the risk of errors. 
Product Considerations 

a) Are there any Problem Management tools identified? 
Problem Management tools log error information, gener- 
ate error reports (such as System Investigation Reports or 
SIRs), classify problems, and record information on the 
source of the error. Problem Management tools are essential 
for the capture of stage containment metric information. 

b) What engagement factors affect the use of Problem 
Management tools? 

Risk rating of the engagement — In general, management 
and planning tools help better Address the engagement 
risks. A high risk rating for the engagement affects 
positively the decision to use tools such as Test 
Planning, Test Data Management, Problem 
Management, and Configuration Management. 

Criticality of the engagement — In general, management 
and planning tools help better manage the engagement 
and ensure the timely delivery of a quality system. 
Therefore, dealing with a highly critical engagement 
will most likely affect positively the decision to use 
tools such as Test Planning, Test Data Management, 
Problem Management, and Configuration Manage- 
ment. 

What testing team factors should be considered when 
using a Problem Management tool? Communication 
between development team and testing team — Prob- 
lem Management tool can be used to track issues, 
design changes, and so on, and serve as a communi- 
cation tool between teams. As part of a Change Control 
mechanism for the engagement, such a tool can help 
improve communication between the development and 
testing teams. Thus, bad communications between 
teams can still have a positive influence on the decision 
to use Problem Management. 
Size of the testing team — ^The size of the testing team has 
an impact on the decision to use a Problem Manage- 
ment tool. If the testing team is large, keeping all team 
members informed on the status of identified problems 
is a more complex endeavor than with a small team. 
The larger the testing team, the more benefits will be 
derived from using a Problem Management tool to 
support testing. 
Similarly, the larger the testing team, the more benefits 
will be derived from using a Test Data Management tool 
(easier control over the test data for the various testers), a 
Configuration Management tool (easier control over all 
system configurations and component versions) and a Test 
Plan Management tool (easier control over all test cycles, 
subcycles, their execution statuses, and so on). 
System Building (278) 

System Building tools comprise the core of the develop- 
ment architecture and are used to design, build, and test the 
system. All the system building tools must be integrated and 
share development objects appropriately. 
Analysis & Design (228) 

Analysis tools are used to specify the requirements for the 
system being developed. They are typically modeling and 
diagramming tools, which provide the ability to diagram 
system requirements and specify "what*' a system must do. 

Design tools are used to specify "how" a system will 
implement these system requinsments. They are typically 
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diagramming tools, which graphically depict how the sys- 
tem will be built in terms of its key components. Tliis differs 
between classical client/server systems and component - 
based systems: 

5 The standard cUent/server model comprises application 
logic, presentation, and communication components, which 
together support the business processes. For a client/server 
system, each of these components must be individually 
defined. 

10 The component-based systems, however, have the data 
model and process models encapsulated within the object 
model. In addition, the design of the component model is 
directly affected by the business processes which govern the 
way these objects interact. Therefore, with component-based 

15 systems, the object and component models encapsulate the 
data and process models. 
Data Modeling 

Data Modeling tools provide a graphical depiction of the 
logical data requirements for the system. Tliese tools usually 

20 support diagramming entities, relationships, and attributes 
of the business being modeled on an Entity-Relationship 
Diagram (ERD). 

As systems are often built on top of legacy databases, 
some data modeling tools allow generation of an object 

25 mocbl from the legacy database data model (DDL). By 
understanding the E-R diagram represented by the database, 
it is easier to create an efficient persistence framework which 
isolates business components from a direct access to rela- 
tional databases. Caution is required, however, as the result - 

3D ing model is at best only partial, as an object model has 
dynamic aspects to it as well as static relationships, and may 
not correctly reflect the analysis performed in the problem 
domain. 

When a component or object-based approach is used, data 
35 modeling is not performed. Rather, the object model con- 
tains both the data and the behavior associated with an 
object. In most systems relational databases are used and the 
object model must be mapped to the data model. Standard 
mechanisms for mapping objects exist. Tools such as Per- 
40 sistence (Persistence Corp.) and DBTools (Rogue Wave) can 
generate the code necessary to map objects to a database. 
Implementation Considerations 

a) Can the development process benefit from a DDL gen- 
eration tool? 

45 Data mode hog tools allow DDL to be generated from the 
data model. The tools should support DDL generation for the 
chosen RDBMs (Sybase®, Oracle®, DB2®). In addition, 
the DDL generator should take advantage of the specific 
advanced features supported by each of the RDBMs. 

50 b) Can developers benefit by a graphical depiction of the 
logical and physical data requirements? 

Data modeling tools help to graphically develop the 
logical and physical data requirements for an application. 
These tools depict logical constructs such as entities, 

55 attributes, and relationships between enuties, along with 
physical constructs such as database definitions and table 
indices. 

It is useful for developers to have read-only access to 
either a hard or soft copy of the data model during devel- 

60 opment. This document rapidly becomes a key discussion 
document in design discussions. It is useful to show tables, 
columns, primary keys, and foreign keys (if all of this will 
fit on a diagram at the same time!) in the document 
Graphical depiction is not only useful but essential to data 

65 architects, DBAs and also to apphcation developers (the 
latter group is often omitted). As in most cases, a picture 
speaks a thousand words. 
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c) Is there a need for consistency in data across applications? design is not. This design is highly dependent on the 
Data modeling tools promote consistency in application platform components and may need to be repeated for each 

development by defining standard names and attribute char- location type and platform type. This process is simplified if 

acteristics for the application data. Application developers a data model is used. 

then use the standard entity and attribute definitions across 5 ],) Does the system interface with external systems having 

various application development initiatives. This results in a ^gj^ ^^^^ definitions? 

consistent definition and usage of data. For example, all Date modeling tools allow documentation of the data in so 

applications that require customer number wUl use the f„ ^ j^j^ ^^j^, ultimately in the 

standard name and altnbute length defined m the data model. However, there is usually a significant number of 

Database adm.nisiratoB wiU ^ use the data model to ^^^^ definitions which will never appear in the 

generate physical database defin.t.ons that aie consistent ^^^^^^ ^^^^ jgg^j,j^„ ,^ j^,^ 

with the application under development^ Thus, the data ^.^j^^,^ ^ ^^5, ^^^^ i^,^^^^^^ ,^ 

model acts as a smgle source for data defimtion. ^^^^^^^ ^ .^^^^ ^ , ^^^^^^ 

AU apphcauons should have data consistency mat is whose data definitions may differ to those on the data model, 

finked back to a set of business data standards. Failure to ^^^^ ^^j^j, correspond to fields on the model, 

achieve an agreed set of definitions will jeopardize the ^^^^ definitions must also be documented and stored 

ability of the separate apphcations to perform as a business effectively outside the date model. The data model- 

unit, for example, applications will not be able to share date component should be used to implement procedures to 

if they are m different formats or i^ different code loo^^^ ^^^^ definitions that affect the system. 

Data consistency must be agreed FUNCTIONALLY dunng ^„ p^^^, Considerations 
analysis and design. Date modeling tools will help to docu- j^,^^^^^ .^j, 

mem data defimtioDS but they wiU not automatically enforce ^^^^ ^^^^^^ ^^^^^^ ^ j^,^ ^^^^^^^ ^„ 

data consistency. ... ^ . j ,„ depend on the intended use of the tool. If the tool is to be 

d) Are there more than 100 entitle in the data model? ^^ ^^^^ , j^^, ^^^^^ .^^ ^^^^ 

At this level ofcomplexity a dedicated date modebng tool 35 [^gj^^, constructs such as entity definition, attribute 

IS necessary, , , . definition, subtyping, and supertyping. If the tool is to be 

Does the system incorporate object oriented methods? ^ ^^j^ j, ^^^^ j^^, 

ob-eck?' ° '° P^^'S'^"' constructs required for the targeted RDBMs. such as trans- 

i, , ' t. . , , . • /. . forming a logical model into a physical model, database 

FuUy normalized date models are a different view of the 3^ definition, index definition, and DDL generation, 
corresponding object models. On tlie one hand, tfie date ^„ ^^^^ component satisfy this requirement? 

model does not show behaviors (methods). On the other development architecture may already have tools that 

hand it does show resolvmg enuties that are normaUy j^^^ modeling. For example, many information 

modeled <^ contamer objects and may be mtemal to an „t tools (repository) provide date modeling capa- 

object. A data modehng tool is useful for showing how the 35 ^ ^^^^ ^^^- ^^ f^inaions reduces 

persistent objects map to the relational database. j^„^i„ ^. i • j „ j • . 

, . , ... . the developer Icarnmg curve and provides integration 

e) Is there a need to communicate the busm^ data require- ^j,^ components of the development architecture, 
ments without regard to the DBMS or platform? ^^^^ ^^^^^ ^^^jj^y^ ^.^^ j^,^ ^^^^ 

A data model is a technology-mdependent model of an ^^^y^ 
organization's data requirements consisting of diagrams and ^ ^^■ ^ importent to consider the various utilities available 
descriptions of entity types, attnbute types relaUonship modeling tools. Two such utUities include 

types, and integnty constramts. It is a flexible, non- ^ ^^^j reporting. Impact analysis capabilities 

redundant, non-coiKtraimng model As a simplified repre- ^y^^ ^ understand the impact of a change to the 

sentaoonof reality It has no regaid for such physical matters ^ata model. Impact analysis functionality is one of the key 
ashowdataistobere.nevedorhowlong itw,ll teke.The ^y engagement teams to assist with change 

data model presents a concept of the busmess data in an ^janagement and change control activities. Some products 

idealized ^ructure. It is a useful tool to commumcate the ^, j^^j^^^ ^^^^ generators which are useful for 

scope o e project. generating data and attribute definition reports as well as ad 

f) Is the system complex and changing? [^^^ reports 

Good date modeling requires a full understanding of the ^ j) Does the development team have any prior experience 
busmess data involved. Data modehng becomes more ^^,3 ^.^defing tools? 

important as systems become more complex and sophisti- ^ ^^^eling tool may be chosen based upon prior 
cat«l. The data structures which support such systems must rfence with the tool by the cUent or members of the 

be aexible and be able to accommodate change. The data engagement team. This reduces the learning curve associ- 
model IS the best means of identifymg and representing 5, ^.^j ^^^^ integrating a new tool into the development 

these changes. environment. 

g) Is database design going to be performed? e) How well does the date modeling tool integrate with other 

The finahzed data model is used as a basis for the logical development tools? 
databas^ design The logical databa^ design converts the ^ata modeling tools commonly integrate with the reposi- 
finah^ Project Data Model to one of four basic structures, ^ ^^^^ ^^^^ ^ ^.^^^ -^^^^ 

accordmg to which DBMS is used: Apphcation Logic Design tools. If the tool does not 

Hierarchical (rarely used today) pj^^ide seamless integration with other components of the 

Network (e.g., IDMS) development environment, the engagement team can build 

Relational (e.g., DB2) bridges between components, or develop manual procedures 
Inverted List (e.g., AD ABAS) 65 in order to share information. It is important to consider how 

Although entity-relationship diagrams are independent of the data modeling tool integrates with the design repository, 

specific DBMSs or access methods, a logical database It is important to maintain a cross-reference of the attributes 
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on the model, with the definition of data elements in the model can provide an effective means of bringing people 

design repository. Such data element definitions will also together, creating a shared vision of how the business is to 

address non-database data definitions (e.g. external i/face function. 

files). b) Do the processes vary from region to region and need to 

f) What level of data modeling is required? 5 be standardized? 

During the early conceptual design, data modeling need A process model provides a means of standardizing a set 

not be very detailed. It should be a participative, team of similar processes which exist, for example, at different 

activity, and is usually very unstable. In this case, a tool such branches of the business. 

as a white board or PowerPoint will suflBce. c) Does the project include process re-engineering or 

As the design becomes more detailed, more sophisticated process-streamlining? 

tools are needed. At the lowest level of detail consistency is The re-engineered processes in the process model may 

vital and a repository-based tool can be used to ensure form a basis for the systems design which is to come 

consistency across the data model. afterwards. Requirements and constraints for the system 

g) Should the data modeling tool provide database design design can be well represented and communicated in a 
facilities? process model. 

There are some tools which do not incorporate this d) Is process simulation required? 
feature, such as ARIS, which is strictly a data modeling tool. . Advanced process modeling tools provide process simu- 
'This may be helpful to guard against moving too far into the lation capabilities. Process simulation ensures that the pro- 
design during the analysis phase. cess design is adequate as a basis of the functionality of the 

Most data modeling tools allow you to develop the software that is to be developed, 

database design at the same time. This has the advantage of 20 Product Considerations 

keeping costs down as two separate tools need not be a) What approach is to be used for process modeling? 

purchased, and of ensuring consistency by providing a direct The tool may need to support the creation of business 

interface between the two phases. function decompositions or data flow diagrams depending 

h) Does the data modeling tool support submodeling? on the approach used. 

Subraodeling enables complex models to be broken down 25 Data flow diagramming is used when the application has 

into smaller more manageable and xmderstandable models a complex or innovative workflow or if the analysis and 

while still maintaining unique object definition. This is design teams have little experience with the application, 

particularly important for large teams where data modeling Business function decomposition is used when the appli- 

is divided among several teams. cation is fairly routine and the team has extensive experience 

i) Does the data modeling tool provide support for a muiti- 30 with similar applications. 

designer environment? b) Does another component support procedure diagram- 

The information management component may provide ming? 

the security needed in a multi-designer environment. If this A business function decomposition diagram can be pro- 

is not the case then a multi-designer data modeling tool duced using a procedure diagramer. 

should be used. The tool may provide a central dictionary 35 c) Are common process symbols to be reused? 

which allows design data to be shared between several The tool should provide a facility to create custom sym- 

designers and includes security checks to monitor any bols for the process flow and these should be reusable, 

conflicts in overlapping access rights between designers. d) Does the tool support the expected size of the process 

j) Does the tool provide facilities to add color to the data model? 

model? 40 The process model may include hundreds or even thou- 

The facility to add color to the data model is useful for sands of processes. The tool should be able to support the 

communicating additional dimensions such as data owner- expected size of the process model, 

ship. e) Does the data flow diagramer support leveling of dia- 

k) Is entity life history required to be documented? grams? 

The data modeling tools must support a facility for ELH 45 Some tools allow leveling of the diagram in which a 

modeling for entities that have their status changed by a process box on a high level diagram is decomposed into 

wide range of events. Any entity which has an attribute multiple pnDcesses on a lower-level diagram. To ensure that 

containing the word status is a likely candidate. the diagrams are easy to understand and that they easily 

I) At what point should inconsistencies in the design be convey information, it is useful to keep the diagram size to 

controlled? 50 one window or one printed page. The facility to level a large 

Designs should be consistent. However, enforcing inter- diagram can help to achieve this, 

nal consistency at all times can lead to design gridlock which f) How does the data flow diagramer support data stores that 

prevents innovation or progress. The tool should support the are used by more than one process? 

project decisions regarding consistency. It is often the case that processes that share a data store 

Process Modeling 55 cannot be placed near each other on the diagram. To avoid 

Process modeling tools provide a graphical depiction of complicating the diagram, some tools allow data stores to be 

the business functions and processes being supported by a depicted more than once on the diagram. The tools may 

system. The tool(s) selected must support the modeling provide facilities to differentiate these stores from stores that 

techniques being used in the development methodology. have not been duplicated in this manner. 

These include process decomposition, data flow, and process 60 g) Can control flows be represented by the data flow 

dependency. diagramer? 

Implementation Considerations It may be necessary to depict control flows. The tool may 

a) Are the processes that the system is to support ill- represent these as data flows without any data elements, such 

understood or is there fitlle consensus on what these pro- as, for example, a signal from a timer fimction. 

cesses are? 65 h) Does the tool support validation of the diagram? 

Process modeling is a method for clarifying and commu- To ensure that a data flow diagram is complete, each 

nicating the business design of the system. The process process should have at least one input and one output. 
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Unless data stores are shared with other systems, each 
attribute of each data store must have at least one input flow 
associated with it. The tool should facilitate the identifica- 
tion of exceptions to these general rules. . 
i) Is a detailed process model with complex processes to be 5 
documented? 

At the lowest level of a data flow diagram or a business 
function decomposition, there may be processes that are still 
too complex to be explained by a label or even a short 
paragraph. For example, this may be the case if complex lO 
interest rate calculations are to be performed by the process. 
An elementary process description may be required for each 
such process. The process modeling component should 
include tools that enable the description to be documented. 
The description may be formatted as plain English, struc- 15 
tured English (resembling pseudo-code), decision tables, or 
as action diagrams. 
Event Modeling 

Event modeling tools provide graphical depiction of the 
events and associated responses for the system. A variety of 20 
tools and techniques can be used for event modeling, for 
example, word processors to develop simple textual lists of 
events and data flow diagramming to show events and 
responses. 



For component-based development, event modeling or 25 year end event. 



Applications can generate events as required to ensure 
that appropriate next steps in the process are performed after 
they have completed their part. 

e) Is a real-time system to be developed? 

Real-time systems require very strict responses to events 
within specified time frames. Event modeling is critical to 
ensure that real-time systems meet this requirement. 

f) Is the extent of change to the business particularly large 
such that a detailed requirements model is needed? 

The requirements mcwdel (event, process, and data models) 
provides a clear means of depicting the system. The require- 
ments model summarizes the relationship between events, 
data, and processes. It consists of the event model, the 
process model, and the data model. The event model is 
important because it details the business transactions and 
events enough to understand the process and data models. 
Event modeling tools must be provided to complete the 
requirements model. 
Product Considerations 

a) Do other tools provide the required functionality? 
Event modeUng and process modeling go hand in hand 

and are typically provided by the same tool. 

b) Are events triggered by time easy to represent? 

The modeling tools chosen should provide a means of 
clearly depicting events that are triggered by time e.g. the 



interaction sequence modeling may be performed through 
interaction diagrams, both at the object and component 
level. The event model is often used as input for test 
scripting. 

Implementation Considerations 30 

a) Is there a need to capture the essence of how the business 
functions without becoming tangled in the current sequence 
of processes? 

Event modeling does not fix the sequence of processes. A 
process starts when a specified event occurs, and may 35 
generate other events when it has finished. Event modeling 
notation allows focus on what steps the process must do as 
opposed to "how*' it sequences the steps. This form of 
representation is especiaUy useful for processes that will be 
re-engineered, since it allows steps to be re -arranged easily. 40 

b) Is there some uncertainty about the functional require- 
ments or scope of the system? 

An event model represents external actions which the 
system must recognize and responses which the system must 



c) Does an existing component provide all the necessary 
facilities? 

A flow charter is generally required to graphically depict 
the events. There is also a text description of the events 
which can be documented using a tool such as MS Word® 
or MS PowerPoint®. Entity life cycle diagrams, Event- 
Stimulus-Response diagrams or matrices, or Context dia- 
grams may be required to complete the model. 

d) Is the system complex? 

As the number of events increases, the complexity of the 
event model increases and the diagramers may need to 
support certain facilities such as intelligent connectors. 
Simple graphics packages may not sufiSce at this level. 
Performance Modeling 

The performance of a system must be analyzed as early as 
possible in the development process. Performance modeling 
tools support the analysis of perfonmance over the network. 
A simple spreadsheet may be suitable in some well-known 
and understood environments, but dedicated performance 



produce. Events express the system *s perception of external 45 modeling tools should be considered on any project with 



activities. Therefore, event modeling allows the external 
environment to influence the requirements definition, rather 
than basing the environment on the applications structure. 
This approach supports the applications consistency with the 
workflow and other business activities and thus clearly 
defines the scope of the system. 

c) Are the business requirements of the system to be com- 
municated to a large team or to the users? 

An event model represents the user requirements in 



concise business terms. When used in conjunction with the 55 system. 



high transaction volumes or complex distributed anchitec- 
tures involving several platforms. 

In the case of Inter net -based applications, as the Internet 
is not a controlled environment, performance modeling is 
50 limited to those components within the domain of the 
controUed environment (i.e. up to the Internet Service 
Provider). However, In the case of intranet-based systems, 
where the environment is controUed from end-to-end, per- 
formance modeling may be performed across the entire 



process model, this provides an effective means of commu 
nicating the system requirements from the business design 
team to the systems design team or to the users, 
d) Does the architecture have several disjoint systems that 
need to respond to the same business event? 

By using event modeling and a central event router 
architecture, interfaces to several systems can be easily and 
flexibly provided. Each system registers itself with the event 
router and indicates which business events it is interested in. 



Performance modeling for components involves the 
analysis of the projected level of interaction between com- 
ponents and the level of network traffic generated by this 
interaction. It is important for performance reasons that 
60 communication between components is minimized, espe- 
cially if these components are distributed. 
Implementation Co nside radons 
a) Is the system complex or heterogeneous? 



A performance model ensures that performance require- 
Whenever an event is triggered, the router is notified. It then 65 ments are met in a complex or heterogeneous environment, 
triggers all the applications that registered themselves as Performance is usually a critical quality requirement in such 
being interested in that event. environments. 
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b) Does the system involve extensive communication over a Class Interaction or Sequence Diagram (1 or more per 
Wide Area Network? scenario/workflow) 

The complexity involved in designing systems over a Class State Transition Diagram (1 per Class with complex 

WAN makes performance modeling tools critical to success slate) 

for such systems. 5 specific modeling tools can provide advantages such as 

c) Are there hundreds of users?Are there tens of servers? ^^^^ referencing (for example, are all the methods used in 
Due to the complexity of such systems, performance the Interaction diagrams described in the class definitions?), 

modeling tools are important in ensuang performance automatic propagation of changes to other diagrams, gen- 

requirements are met. ^^^^-^^ reports, and generation of skeleton code. 

d) Do experience and benchmarks indicate that there may be ,o However, some tools have problems with: 
diflSculties in meeting the performance requirements as Usabilit and stabilit 

stated for the system? ^ ^ 

In this case performance modeling tools are critical, since ^mgle users or small numbers of concurrent users 

penalties may be incurred if the system does not meet the Proprietary repositories (usually file-based, rather than 

performance requirements. A performance model provides a ^5 DB-based) 

means of deciding early on whether the system is feasible or Support of extensions/customizations 

not. . As well as providing the usual editing and graphical 

e) Is what if analysis required for future growth? functionalities, a good modeling tool should: 

f) Is what if analysis required for alternative hardware Interface with a repository (to support versioning) 
configurations? 20 Support multiple users 

g) Is what if analysis required for hardware loading? Generate code fi-om the design 

Performance modeling tools provide a means of analyzing xhe use of UML notation to represent the object model is 

how much future growth or what alternative hardware becoming more and more common. In this case other 

configurations can be sustained before the system breaks diagrams such as Use Cases and Collaborations Diagrams 

down. This component may be needed even though it is 25 complement the model, 

obvious that the system will meet the current performance Component Modeling 

requirements. Component modeling can mean either designing compo- 

h) Are high transaction volumes or complex architectures Qgnts from scratch, or customizing and integrating packaged 
expected for the system? software. No specific component modeling tools exist, and 

Dedicated performance modeling tools should be consid- 30 current object modeling tools only offer limited support for 

ered for any project that involves high transaction volumes components (e.g. for packaging related classes together), 

or a complex architecture with several platforms. Perfor- Class packages can be used to separate the object models for 

mance is critical for such systems and a performance model different components, with a separate class package(s) for 

is required in order to predict and optimize that performance. the component model. This approach, however, is not 

Product Considerations 35 enforced by current modeling tools, and requires project 

a) Does a generic tool such as a spreadsheet package sufiSce naming and structuring standards. 

as a performance modeling tool? when component modeling is being performed using 
A specialized performance modeling tool should be used existing packaged software, some form of reverse engineer- 
when the system is complex and involves high volumes of i^g or importing is required from the modeling tool to 
data, or is heterogeneous. 40 capture the existing design. 

As design progresses from high level conceptual design to During component design the partitioned component 

detailed design, to technical design, there is a corresponding model is designed, which defines physical interfaces and 

sequence of activities involved in performance modeling. As locations for components. It is important for performance 

the design becomes more detaQed, so does the performance reasons that communication between components is 

model. The model may start as a simple spreadsheet and 45 minimized, especially if they are distributed, 

evolve into a collection of spreadsheets with many sheets in Reuse Support 

each book. As the structure and parameters become over- n during analysis and design that really large savings 

whelmingly complex, a dedicated modeling tool with its can be obtained by reusing existing solutions. At this stage, 

own data model, user interface etc. is a good investment. reuse is often at the subsystem level but can extend down to 

A performance modeling tool should not be purchased 50 the service and module level. Asset navigation tools, which 

due to a lack of understanding or inexperience of perfor- permit the retrieval of reusable components, can therefore be 

mance modeling, since the tool will not clarify the issues any of great value. 

more than a spreadsheet model. For a component-based or object -based solution, reuse is 

b) Does the tool allow empirical data to be fed back into the usually with a specific aim. It occurs at different levels and 
performance model? 55 requires different types of support. 

Performance modeling must be backed up with empirical At the analysis and design stage, common classes and 
data at the earliest possible stage. Initially, this will be components are used across applications. Repository man- 
through perfomiance benchmarking usually using a small agemcnt is required that allows easy browsing and sharing 
equivalent of the production system. The results should be pieces of design. 

fed back into the perforaaance models to improve their 50 During the construction phase, there may be strong inter- 
accuracy. There should be a means of differentiating empiri- dependencies between the core classes and the components, 
cal data from estimates in the model. xhis must be taken into account when planning the work. 
Object Modeling When classes and components are being fixed or modified. 
An object model usually contains the following deliver- impact analysis tools are needed to see where the modified 
^^^^s* 65 entity is being used. This is more complex than traditional 
Class Diagram (1 per functional area or 1 per component) systems as a veritable spider's web of dependencies between 
Class Definition (1 per class) classes, components, and applications may ensue. In 
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addilioQ, OO features such as inheritance and polymorphism client to the host), to ensure that the system is not based on 

make tracking down dependencies with simple text search an architecture that is fundamentally flawed. 

tools much more difficult. U is important to determine whether to carry forward and 

In terms of tools, a class or library browser is required, extend the prototype, or throw it away after requirements 

which aUows easy navigation and identification of candidate 5 have been determined and perform technical design from 

components and classes. scratch. Some prototyping tools offer the possibiUty of 

In many cases, there can be a mismatch between design reusing code from the prototype. Although this is a valuable 

and buikl, especiaUy if no detaUed design phase exists. This option, it is often available at the cost of slower prototype 

may result in the existence of two repositories. The object or development. An interesting compromise may be to keep 

component model produced in the design phase is at a higher 10 portions of the prototype (for example, user interface 

level and gives a good introduction or overview. The actual components) and rebuild other components from scratch, 

code, however, is where developers tend to go to find out component based development, prototyping may be a 

how an application reaUy works. When this is the case, the valuable way of checking that component boundaries are 

source code can be used as the detailed design. There are defined. However, this impUes that the architecture 

tools that extract documentation (from comments in a given 15 ^^^^ ^^^^^^ ^t the time of prototyping, 

format) and generate HTMLpages. Examples of such tools gp^^g^ multi-platform prototyping facilities may be 

mcluae: required when developing and deploying applications across 

Java— javadocpart of the jdk multiple platforms. 

C++— available from http://www-users.cs.umn.edu/ Prototyping functionality is usually included in Integrated 

-kotula/cocoon/cocoon.htm 20 Development Environments (IDE). 

The ideal situation is a single repository for analysis, WARNING: If the prototyping tool used is not part of the 

design, and code, allowing developers to move from design execution environment, the use of features that are difficult 

to code and vice versa. However, most tools have propri- ^ implement in the target environment ^ould be avoided, 

etary repositories and their import/export facilities are not Prototypes wiU set user expectations, which may be difficult 

sophisticated enough to merge the two. For the moment, 25 to meet once construction starts. Specifically, it is important 

source code and design documentation remain two separate ensure that the performance of the prototype does not 

repositories. exceed the projected performance of the target system. If 

Prototyping yg^r expectations are built upon a highly-performant 

It is frequently difficult to obtain specific, rehable, and prototype, there is the potential of considerable disappoint- 
complete requirements that truly express what users need. 30 jnent when the final system is rolled out. 
TTiis may stem from users being unavaUable or inexperi- implementation Considerations 
enced with computer systems, or it may arise from the nature ^ ^ system run on multiple platforms? 
of the system under design. For example, if the system if so, it may be important to ensure that the prototype also 
mcotporates very new technology, it may be difficult for ^„ ^^^^- ^^ platforms (particularly if the prototype is a 
uset^tov^uahzethepossibihties ^ . , technical prototype as weU as a fiinctional one). 

Prototyping can address this problem by suDulating key ,^ appUcation performance an important consideration? 

user interface components thus enabhng the development prototyping tools can be used to identify potential per- 

team to measure the usability of the proposed system at a ui i- a j f . * 

™ . • ^ . c , . • formance problems m an application, A development team 

very early stage. The most important quality of a prototyping . * • * i * • 1 . c 

, i- ;. , » J If .* - u can use a prototyping tool to implement a portion or an 

tool is its development speed. If prototyping can be per- 40 i- . j .-r . 1 Vi_ . 

- J . . J *L 1 apphcation to identify pertormance problems. I ne team can 

formed in hours or days rather than weeks or months, it ^ • r . • j • j 

. ui * f •* u 1 then use this mformation to improve designs and provide 

becomes possible to perform more Iterations, which explore . , ,. 1 . . j r J - -r-T . . 

. ^ . ™ . 1 J . u u . guidelines and standards tor designs. Thus, prototyping 

different options. This may lead to a much better system, fj. - j j -.. j jf 

. , . • u L • leads to a better designed and more consistent end product, 

given that the user s perception mamres with each iteration. x , , . • . ^-.ttw r. 

This, in turn, improves the quality of user input. 45 ^) expcnence with GUIs? 

Very rapid, low-fidelity prototypes (for example, paper- Prototyping tools allow engagement teams to demonstrate 

based) play an important role in early prototyping. the look and feel of an application to the end user. The tool 

Hi-fideUty prototypes, used later on in the design process, ^^^^^^ capable of providing a reaUstic understanding of 

should be as close to the target system as possible, and the final application without requirmg an extensive constmc- 

highly detailed — even down to the characteristics of a button 50 effort. 

click (e.g. click-down image, click sound, length of click Prototypes can be used to interactively gather business 

etc.). This way, everyone (including the design teams) can requirements and design the application with the end user. If 

determine exactly what the final system should look like. the tool supports interactive prototyping, changes can be 

User involvement at the prototype stage is of the utmost quickly incorporated into the prototype and demonstrated 

importance — regular user reviews as the prototype evolves 5S hack to the user. This is important when users are inexpe- 

wiU ensure buy-in from the users, and avoid unpleasant nenced with GUI. Prototyping the look and feel of the 

surprises at later stages of development. appUcation and interactively gathering business require- 

Caution must be taken not to raise the expectations of the ^ents assist in gaining user acceptance of the system, 

users in terms of the length of time it will take for the final d) Are the system requirements ill defined, vague and poorly 

product to be dehvered. Prototyping will deliver something 60 understood? 

that looks like it "works" very quickly It should be clear that A prototype provides a means of communicating what the 

what is delivered is a model and not an application. Clients system is intended to do and can clarify system require- 

may expect real application functionality to be developed ments. The prototype may become a throw-away if it 

and delivered quickly due the fast turnaround of the proto- becomes clear that the development style of the prototype is 

typing process, which will invariably not be the case. 65 not conducive to a quaHty product. It is often more cost 

Prototypes may also be used to prove architecture con- effective to start afresh incorporating the added understand- 

cepts (for example, to verify the flow of messages from the ing which was developed during the prototyping stage. 
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e) Are the user requireraeols vague? 

It is frequently difficult to obtain specific, reliable, and 
complete requirements that truly express what users need. 
Prototyping can solve this problem by simulating key user 
interfacing components. User interface issues which are 
detected later are generally costly to change. 
0 Is this a high usage and dedicated system, where through- 
put matters? 

If the system is to be used by dedicated people where the 
measure of productivity is solely the number of transactions 
they can get through per second, then user interface proto- 
typing tools are important. Prototyping tools provide a 
means of getting to the easiest and most efficient interface. 
Prototyping tools facilitate selection between alternative 
styles of interaction and provide a means of addressing 
performance issues. 

g) Do the users have a choice of whether or not to use the 
system? 

User interface prototyping tools are important since they 
allow developers to obtain user input early on in the GUI 
design process. This induces user ownership and acceptance 
of the system. 

h) Is user input a criterion for getting the system adopted, 
such as might be the case when a union or organized labor 
is involved? 

By using prototyping tools to get user input, ownership 
and acceptance of the system is facilitated. Adoption of the 
system by users and ensuring that their expectations are 
reasonable can make the system less expensive to deploy. 

i) Does the technical architectural design use new or unfa- 
miliar components or does it use a proven system? 

Prototyping the technical architecture provides an ideal 
way to quickly determine if the design is feasible before a 
major commitment is made to a design that cannot work, 
j) Are selected parts of the system to be piloted on the 
project? 

Portions of the application could be selected for design 
and coding in advance of the full-scale design/code effort. 
This will help iron out architecture issues, user design 
preferences, standards, designer/development training 
requirements, and produce quick wins for the project which 
can build morale for the team and client. A prototype can 
serve as a means of identifying the portions to be piloted, 
k) Are new team members likely to join throughout the 
project? 

A prototype can serve to quickly familiarize new team 
members with the user requirements, reducing the ramp-up 
time for new team members. Project team members should 
be familiar with the goals and use of a system in order to 
effectively develop an application. 

I) Is the project management team unfamiliar with the 
development team they will be working with? 

Prototyping allows the project management team to judge 
the capabilities of a development team with whom they are 
unfamihar. The prototyping effort allows some preliminary 
assessment of skill sets. 

m) Is there some uncertainty about the product to be used in 
construction? 

Prototyping can allow the project team to validate the 
capabilities and characteristics of products which will later 
be used for development. Many products (PowerBuilder, 
Visual Basic, etc.) are marketed as being the best, but may 
fall short of project requirements. Use of such tools during 
prototyping allows some "qualification" of a product's true 
capabilities. Performance, compatibility with existing client 
infrastructure, etc., can be tested. 

Use of a product during prototyping (that is early 
purchasing) also allows a development team to determine 
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the quaUty of the technical support within the company 
providing the product. It also allows time to work through 
some of the business models of those companies (their 
willingness to negotiate on issues, pricing, etc.). 
n) Is system performance an important factor? 

Prototyping and benchmarking the performance of a 
technical environment enables possible performance prob- 
lems to be identified as early on as possible, 
o) I>o the users have little or no experience with the interface 
technology? 

Prototyping serves as a means of introducing the users to 
the interface. Problems the users may have in working with 
the interface can be identified early on, and can be accounted 
for in training materials that are developed. 
15 p) Is there a high degree of innovation in the work flow? 

Prototyping allows the developers to experiment and, 
with input firom users, come up with the best solution to a 
new and unproven workflow. 

q) Do the project team and client fully understand the review 
20 and sign-off process? 

Prototyping allows the project team and the client to work 

through the issues and mechanics of the review and sign-off 

process prior to the intensive development phase. 

Product Considerations 
25 a) What is the purpose of the prototype deliverable? 

b) Is the deliverable used to document the design of the 
application or provide an accurate depiction of the look and 
feel of the application? 

An engagement team should select a prototyping tool to 
30 support the level of detail for the prototype deliverable. 
Initial application prototypes may use low-fidelity prototyp- 
ing techniques (prototypes built using MS PowerPoint or 
pencil and paper, etc.) in order to document initial window 
designs and determine dialog flow (navigation). Some 
35 advantages of low-fidelity prototyping include little or no 
learning curve, lack of standardization which increases 
designer creativity, and ease of modification. However, this 
type of prototyping can not provide the user with the look 
and feel of the final application. High fidelity prototypes 
40 require more sophisticated tools which can provide a more 
realistic depiction of the application. 

c) Is the prototype demonstrating the application behavior to 
the users? 

d) Is the depiction of application behavior used in develop- 
45 ment decisions? 

A prototyping tool should deliver an accurate depiction of 
the application including window flow and business func- 
tions. The prototyping tool should a flow the display of data 
in a window with the look and feel of the navigation. 
50 e) Is reusability of prototype deliverables a requirement? 

f) What is the objective of the prototype? 

Depending on the objectives and timing of the prototype, 
all or part of the prototype deliverable can be reusable during 
later stages of the application development process. Some 
55 projects create prototypes in the very early stages of design 
to demonstrate the capabihty of the tool and obtain user 
acceptance, rather than gathering business requirements and 
documenting design based on the requirements. If the objec- 
tive of the prototype is to document designs based upon 
business requirements, then prototyping tools should be 
chosen with reuse in mind. 

g) Is the prototype used to gather business requirements? 

h) Is the prototype developed during Joint Application 
Design (JAD) sessions with users? 

The prototyping tool should be easy to use so the appli- 
cation designer can quickly incorporate changes to the 
prototype. User input should be incorporated as quickly as 
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possible into the prototype and demonstrated back to the 
user. This helps to acquire user sign off on the application 
design and to gain acceptance of the application- 
i) Does the prototyping tool support reuse? 

Prototypes often represent a large investment, and in 5 
situations where a prototype is successful it should be 
possible to reuse the prototype in the remaining construction 
process. 

Although prototyping tools may have the facility to 
provide reusable code for the system development, it is often lO 
available at the cost of having a slower prototyping tool. The 
reuse of code may not be a good idea since some of the 
design methods used for prototype development may not be 
suitable or desirable for application development. 

Another option which is supported by some tools is that 15 
certain prototyping components can be reused e.g. window 
definitions. The tool selected for prototyping should allow 
easy transfer of the required components into the develop- 
ment environment. 

j) Can the prototyping tool be used to design and build the 20 
front end? 

The prototyping tool could also be the tool that will be 
used to design and build the front end. Using the same tool 
eliminates double entry of repository information and 
reduces the chance of errors when prototype information is 25 
transferred to the application design phase of the project, 
k) Docs the prototyping tool support functionality not pro- 
vided by the construction tool of choice? 

If the prototyping tool provides functionality not available 
in the construction tool then standards need to be put in place 30 
to ensure that the development team only produce the 
prototypes using features that can be implemented in the 
development enviroomenL The amount of additional effort 
required to develop features that are easy to implement with 
the prototj^ing tool but which require work-a rounds in the 35 
construction tool should be a consideration. Prototyping 
features which cannot be delivered will result in failure to 
meet user expectations. 
Application Logic Design 

Application Logic Design tools are used to graphically 40 
depict an application. These tools include application 
structure, module descriptions, and distribution of functions 
across client/server nodes. 

A variety of tools and techniques can be used for Apph- 
cation Logic Design. Examples are structure charts, proce- 45 
dure diagrams (module action diagrams), and graphics pack- 
ages to illustrate distribution of functions across client and 
server 

Application Logic Design functionality is also provided 
by a number of Integrated Development Environments 50 
(IDEs). (see Tools — System Building — Construction) 

With component-based development. Application Logic 
Design is performed through object and component model- 
ing. The functionality is captured in use cases, scenarios, 
workflows and/or operations diagrams along with interac- 55 
tion diagrams/sequence diagrams (See Object Development 
Methodology for samples of deliverables). These are uaially 
produced using an object modeling tool. 
Implementation Considerations 

a) Is there a need for logic representation? 60 
Use Application Logic Design tools to graphically depict 

the logic of an application. This is a common requirement on 
most engagements. 

b) Is there some uncertainty about the validity of the 
business case? 65 

The Application Logic Design tools provide a means of 
confirming the complexity estimates and hence facihtate a 
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revision of estimates before going into construction. By 
confirming the validity of the complexity estimates, the 
business case is also confirmed. It is at this stage that the 
decision is made whether or not to continue with construc- 
tion. 

c) Is performance modeling required? 

Application Logic Design tools can provide a basis for 
performance modeling, based on the processing ability of 
the CPU, parallelism, and pipelining. The tools can be used 
to graphically depict system complexity, from which a 
performance model can be derived. 

d) Is the programming team inexperienced? 
Application Logic Design tools provide a vehicle for 

communication from designer to programmer. This is par- 
ticularly important when programmers are relatively inex- 
perienced and need detailed guidance, which comes from the 
detailed design that is documented using these tools. 

e) Is system maintenance part of the project definition? 
Application Logic Design tools, and the designs that they 

contain, provide documentation of the system which will 
support maintenance in the long run. If the maintenance 
team is very experienced, or if the system is a throw-away 
prototype, which will not be reused or maintained in the 
future, then Application Logic Design tools may not be 
required- 

Product Considerations 

a) Should the engagement team build a custom Application 
Logic Design tool or purchase an existing one? 

Engagement teams must determine whether standard 
design templates provided by vendors meet project needs, or 
if the architecture must provide custom solutions. CASE 
tools tend to provide standard Application Design documen- 
tation. Most custom solutions utilize word processing tools 
to build Application Logic Design shells for use by devel- 
opment teams. 

b) Are several tools to be used to provide Application Logic 
Design facilities? 

A single tool may not provide all the facilities required. 
The different tools must interface with one another in order 
to promote consistency of the Application Logic Designs. 

c) E>oes an existing tool provide the required functionality? 
The development team may require facilities to produce 

procedure diagrams, flowcharts, or pseudocode. These 
facilities may already be provided by existing tools, for 
example, pseudocode can generally be produced by an 
application development tool. 

d) Does the Application Logic Design tool reflect the close 
relationship between application logic and the user inter- 
face? 

In a good GUI program design, the application logic is 
often closely linked to the user interface. A single design 
document capable of capturing this relationship could serve 
as a key input into the programming process. Traditional 
tools only provide separate presentation design and appli- 
cation processing module design documents. 
Database Design 

Database design tools provide a graphical depiction of the 
database design for the system. They enable the developer to 
illustrate the tables, file stmcmres, etc., that will be physi- 
cally implemented from the logical data requirements. The 
tools also represent data elements, indexing, and foreign 
keys. 

Many data design tools integrate data modeling, database 
design, and database construction. An integrated tool will 
typically generate the first-cut database design from the data 
model, and will generate the database definition from the 
database design. 



05/16/2002, EAST Version: 1.03.0002 



us 6,370,573 Bl 
87 88 

Wilh an object-based or component-based solution the Product Considerations 

data modeling task changes. In most cases, relational data- a) Does the product provide the following features? 
bases are still used, even where there are no dependencies on Support for definition of DBMS advanced features (e.g. 
legacy systems. As there is an 'impedance mis-match' triggers, stored procedures, replication, application 

between an object model and a data model, a mapping 5 logic, application generation, referential integrity) 
activity must be undertaken. There arc standard mechanisms Support for versioning and change control 

for doing this. Cross platform and DBMS integration 

There is a tendency (especially when dealing with legacy b) Should the database design tools support database con- 
systems) to treat data models and object models the same. It struction? 

is important to recognize that at best, the data model 10 Many database design tools allow for database construc- 
represents only the static part of the object model and does Such tools may help translate a logical database design 

not contain any of the transient or dynamic aspects. The ^ physical design, or they may generate Data Definition 

physical data model may also change significantly (for DB .^S^^^^^^-^ H^^^, Manipulation Unguage 

optimization), fiirther conftising the issue. (DML)code.The advantage of using a tooUhat pro^^^^^ 

™ . e ui . J facility is that It sunpufies the transfer of design mfonnation 

•mere can be performance problems w,ih objects mapped .5 ^^^^ / ^ i^.i repfesentation and can be used to ensure 

to a relational database. In a worst ci^e scenario an object consistency from design into construction of the daubase. 

can be spread across many tables, with a single select/insert Presentation Design 

for each table, and as each object is loaded one by one, the Presentation design tools provide a graphical depiction of 

performance becomes very poor. Some tools provide lazy the presentation layer of the application, such as windows, 
initiaUzation (only loading the parts as they are needed) and 20 dialogs, pages, navigation and reports. Tools in this category 

caching (minimizing DB hits). include window editors, report editors, and dialog flow 

The current trend seems to be for object-relational (navigation) editors. Window editors enable the developer to 

databases, with vendors such as Oracle adding object fea- design the windows for the application using standard GUI 

tures to their core products. Although the support provided components. Report editors enable the developer to design 
at the moment is limited, it is likely that in future versions 25 the report layout interactively, placing literals and applica- 

Java or C++ classes will be able to interface directly. tion data on the layout without specifying implementation 

Implementation Considerations details such as page breaks. The majority of these tools 

a) Do the design ideas need to be communicated to a large generate the associated application code required to display 
team of developers? these components m the target system 

T^.. J . ^1 J 30 Dialog now (navigation) editors enable the developer to 

Database design tools are important where design ideas u- ii j ■ * *l a c • j 

. • J . J . L graphically depict the now of the windows or screens, 

must be communicated to the development team. Where the Control-Action-Response (CAR) diagram is a com- 

development team exceeds ten people, this design must be technique for specifying the design of GUI 

formalized. Database design tools provide a graphic depic- windows. It is typically developed using a matrix or spread- 

tion of the database design for a system, whilst at the same sheet tool such as Microsoft Excel. 

time enabling the developer to illustrate tables and other xhe majority of Netcentric systems use Web browsers to 

structures that will be implemented physically. provide a common cross-platform user interface. Presenta- 

b) Is system performance a major consideration? tion design for this type of environment therefore entails the 
Database design tools become especially important if generation of HTML pages, often with additional compo- 

performance is critical, since database design contributes nents (JavaScript, 3rd party ActiveX controls. Plug-ins) 

substantially to the overall performance of the system. providing enhanced functionality or media content. Many 

Database design tools provide quantifiable performance data tools are currently available for designing and creating web 

which is a crucial component of the overall performance content, although HTML remains the common denominator, 

jjjQ(jgj at the very least as a placeholder for the content. 

Database Design tools also provide a means to model I/O , ^° ^.^^ ^y^^^^ published on the Internet, defining 
J. L ♦ ij- J. * *5 the target audience IS less straiehtrorward than m traditional 
on devices such as hard disks, optical drives, and tapes etc. , , . »i - i i 

This information can be used in a performance model. ^5^"^?^ but eqoaUy important Having a good underst^d- 

^ ^ . . . ... . . ... tng of the mtended audience will be a big advantage when 

c) Does the project have multiple teams working on multiple ^j^^^i^^g ^^^^^ interaction with the system, and 
functional domains? therefore, the presentation layer of the system. 

The database design component is important in the case Implementation Considerations 

where multiple teams are working on different functional a) Does the project want to use a single tool for prototyping 

domains, since they often model different parts of the and GUI design? 

database separately and then incorporate these models at the Presentation design tools provide the ability to use a 

end into one large database model. Database design tools single tool for both prototyping and GUI design. This 

can be used to enforce consistency of the different database decreases the learning curve during design and permits 

designs. components of the prototype to be reused. 

d) Does the database include a very large number of tables ^) ^ ^^er requirements clearly defined? 

and elements? ^) numerous iterations of design anticipated? 

• \u L 1 u f . • I- These tools make appUcation development easier and 

Navigation through a large number of tables is comph- r ♦ u • * I ^- t u-i *- j u i* • c 

- ^. . i c J • c .1 -f J J- .jj * faster through pomt-and-chck capabilities and built-in func- 

cated and can be simplified significantly if dedicated data- so tions. Reduction in the overall presentation layer design/ 

base design tools are used. development effort allows for more design iterations, and 

e) Are there likely to be conflicting system requirements? thus more chances for user feedback. 

Different teams or users may have different requirements d) Has a specific construction tool been selected for the 

which conflict. These requirements may have to be ratio- project? 

nally traded -off against each other. Where these require- 65 If the tool to be used for construction is not known at 

ments are performance related, the trade-off can only be design time then specific tools for presentation design are 

rationalized on the basis of a good database model. needed. 
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e) Is the design complex? 

f) Does the design have to be presented to multiple users? 

g) Do the users have conflicting interests? 

h) Does the design have to be signed ofif? 

i) Does the design have to be maintained over time? 5 
In these cases a dedicated presentation design tool can be 

used to provide maintainable documentation of the presen- 
tation design which can be used to clarify and communicate 
issues. 

Product Considerations lO 

a) How much does the tool cost? 

Product components, maintenance agreements, upgrades, 
run-time licenses, and add-on packages should be consid- 
ered, 

b) Will the design tool be used for programming of client 15 
applications? What programming language is supported? 

If the design tool is used for programming, there are 
several features of a tool that must be considered. These 
features can have an impact on the productivity of 
programmers, performance of the applications, skill sets 20 
required, and other tools required for development. These 
features include: 

What programming language is supported? Is the pro- 
gramming language interpretive or compiled? Is it 
object oriented or a structured procedural language? 25 
Does the tool support programming extensions to 

Dynamic link Libraries? 
What are the debugging capabilities of the tool? 

c) Will the tool be used with a large development team? 
If the development team is more than 5 people, a tool 

should provide support for multiple developers. This support 
includes features such as object check-in/check-out, a cen- 
tral design repository for the storage of application objects 
and user interface definitions, and version control. 
Additionally, the development team should be able to 
cleanly divide the application(s) into pieces that can be 
worked on by multiple developers. 

d) If the tool is also going to be used for apphcation 
development, how well does the tool perform during pro- ^ 
duction? 

Computational, network, data retrieval, and display 
speeds differ for products. Factors to consider are whether 
the application will consist of heavy data entry, transaction 
processing, or a large user base. ^5 

Does the produa integrate with other tools and/or support 
other tools in the development and execution environments? 

It is important to determine how well the product inte- 
grates with other design and development tools, presentation 
services (graphics, multi-media, etc.), data access services 50 
(databases and database API libraries), distribution services 
(distributed TP monitor), transmission services (SNA, 
HLLAPI, etc.), data dictionary, desktop applications, and 
programming languages for call-out/call-in. Additional con- 
sideration should be given to add-on and third-party 55 
products/enhancements such as specialized widgets, report 
writers and case tools. 

e) Is the tool scalable? 

The tool should be scalable to support growth in appli- 
cation size, users, and developers. 60 

f) What functions are required in the control set? 

At the minimum, a tool should support basic widgets 
(push buttons, list boxes, etc.), window styles, (multi- 
window, multi-document, paned-window), and menu styles, 
along with vahdation and inter-application communication. 65 
Consideration should also be given as to the extensibility of 
the toolset via add-ons and third party products. 
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g) What databases are supported? 

h) What protocols are used to communicate with the data- 
base? 

Important considerations include the supported databases 
and protocols used to communicate with the databases. The 
tool must support the selected database. Additionally, if 
database selection may change, it is important that the tool 
have the ability to support other databases with minimal 
impact on the application development. Native database 
interfaces tend to have better performance than open stan- 
dards such as ODBC. 

i) What level of technical support, documentation, and 
training is required to ensure the productivity of developers? 

The extent of support (on-site, phone, bulletin board, 
world-wide, etc.), quality of documentation, and availability 
and location of education/training should be considered, 
j) What type of learning curve is associated with the tool? 

Developers using the product should be able to become 
productive quickly. Factors which reduce the learning curve 
include an easy to leara and intuitive interface, thorough and 
clear documentation, and on-line help, 
k) Can the tool be used for both prototyping and GUI 
design? 

The ability to use a single tool for both prototyping and 
GUI design will reduce the development learning curve. 
Tool integration with all other development tools should also 
be considered. 

I) What platforra(s) are supported? 

The platform(s) that must be supported, i.e., MS-DOS, 
Windows, IBM OS/2, UNIX, or UNIX Motif, are an impor- 
tant consideration, as are any hardware restrictions, 
m) Is there a need for consistency across multiple screens or 
windows? 

Some presentation design tools provide the facility for 
reuse of elements. This can be used to enforce consistency 
across multiple screens and can accelerate development. 
This feature is not available in low-end presentation design 
tools, such as MS PowerPoint. 

One means of ensuring reuse is for the tool to support a 
central library of predefined widgets or screen elements. 
This library should be extendible and customizable, allow- 
ing developers to create new widget/element definitions or 
to enhance existing ones, 
n) Is multi-language support a consideration? 

Special characters, differences in field lengths, and dif- 
ferences in number formats are some of the things that 
contribute to the complexity of a multi-language application. 
Window and report design are among the areas affected by 
differences in the language used for presentation. 

Strategies on how windows are displayed are affected if 
multi-language support is a requirement. Are separate win- 
dows painted for each language or are window literals 
dynamically replaced? The former will produce windows 
that are more visually appeaUng but requires more signifi- 
cant effort to create and maintain. 

The presentation design tools should facilitate documen- 
tation of these differences for design purposes and allow the 
design strategies to be implemented, 
o) Is the tool integrated with the repository of choice? 

The presentation design tools should be tightly integrated 
with the system components stored in the repository, such as 
windows, reports, screens, and other more abstract models 
to ensiure consistency. 

p) Is a multi-media application to be developed? 

Touch screen hotspots, video clips, hypertext, pointer 
device hotspots and other similar design objects must be 
supported by the presentation design tool if the design is for 
a multimedia apphcation. 
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CoramunicalioD Design 

An increasingly important aspect of system design is 
communication design. After the fundamental communica- 
tion paradigms have been chosen, each exchange must be 
designed to allow for the detailed design of each module 
(clients, services, functions), and to lay the basis for more 
refined performance modeling. To ensure against interface 
problems, these tools should be tightly integrated with the 
design repository. One simple way to document communi- 
cation interfaces is to define include files, which hold the 
. interface definitions. 
Implementation Considerations 

a) Is performance simulation or modeling required? 
Thorough performance simulation or modeling requires a 

communication model. A performance model is particularly 
important if the system is large, heterogeneous, and com- 
plex. 

A valid performance model can only be created once a 
detailed communication design has been developed for the 
system. The performance model is derived from the detailed 
communication design. Communication design tools pro- 
vide a means of documenting the physical design of the 
system, such as protocol stacks, message sizes, routers, 
bridges, gateways, LANs, WANs, MANs, etc. as well as the 
logical design, both of which are used to develop the 
performance model and to simulate performance. 

b) Is the system migrating from a central to a distributed 
environment? 

c) is the system migrating from a LAN to a WAN environ- 
ment? 

d) Is the system migrating from a country wide WAN to a 
global network? 

When development takes place in a mainframe 
environment, performance is relatively predictable. In a 
distributed environment, response time is dependent on the 
communication design. 

Migrating from a LAN to a WAN, or from a WAN to a 
global network will drastically impact the performance of 
the system, and this type of migration requires the devel- 
opment of a complete communication design from which a 
performance model can be derived. Thus, tools to facilitate 
the communication design become a critical part of the 
development architecture when migration of this sort is 
involved. 

e) Is high network performance required? 
Communication design tools are essential in developing 

systems where critical business operations have to have 
maximum availability and minimum down time. One of the 
primary contributing factors to high performance in client/ 
server environments is a good network design. A good 
network design can only be achieved through a good com- 
munication design. 
Product Considerations 

a) Is the tool repository based? 

The best support for detailed communication design for a 
large development team is provided by a repository. Here the 
messages, calls, and queries can be modeled and designed as 
entities in their own right. These entities provide a necessary 
basis for performance and module design, which can be 
shared by all developers. 

b) Is there a need for a graphical depiction of the commu- 
nication design? 

A graphical depiction of the communication design may 
be required. For simple designs, tools such as PowerPoint 
are normally adequate. Dal a flow diagrams may be used to 
show how clients send messages to services. The tools used 
should help developers to ensure that objects in the diagrams 
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are linked to the actual objects (Windows, Services, etc.) in 
the repository. This will maintain consistency of the design 
documentation with the actual objects used in development. 

c) Do existing tools provide the necessary functionality 
5 required to produce the communication design for the 

project? 

A simple and effective method of defining interfaces is by 
using include files to hold the interface definitions. The 
application development tools usually provide this facility, 

A spreadsheet package such as Excel may also be used to 
design message layouts. For simple graphical depictions of 
the commimication design, a tool such as PowerPoint is 
adequate. 

d) Does the tool encapsulate knowledge of the services 
provided by the middleware layer? 

The middleware layer provides the basic functions for 
applications in a heterogeneous environment to interface 
with operating systems, networks and communication pro- 
tocols. 

If the tools used encapsulate knowledge of the middle- 
ware services, low level design of communication (e.g. 
designing at the level of named pipes and sockets) need not 
be supported or investigated. The middleware component 
abstracts this level of detail so that the designers need not 
25 concern themselves with complex technical issues. 
Usability Test 

From a development perspective, systems that are 
designed and tested with usability in mind offer clear advan- 
tages. This is providing Usability Testing is executed from 
the user perspective, and from the very beginning of the 
development process. Usability Testing can help developers: 

Reduce risk by confirming that they are building the right 
solution 

Identify new system requirements 
35 Decrease development time and money by reducing 
rework 

Achieve a smoother conversion, with less disruption to 
business 

Each system is designed to meet the unique requirements 

40 of its users, and therefore benefits from a different mix of 
testing techniques. In many cases, designers find that the 
best starting point is to build and test low-fidelity prototypes 
(see Tools — System Building — Analysis & Design — 
Prototyping), These are paper-and-pencil versions of user 

45 interfaces that allow developers to demonstrate the behavior 
of systems very early in development. Before any code has 
been written, developers build prototypes on paper and test 
them with real users, simulating the human-computer inter- 
action. Designs are adjusted and re tested several times until 

50 a usable solution emerges. When it is time to begin coding, 
developers already have an excellent idea of how the system 
should work and what the users want. 

Once the user interface has been coded, the high-fidelity 
prototype is ready for online usability testing. The test 

55 results are compared with previous tests and routed back to 
the developers. If lo-fi prototypes were used earlier, the 
major design issues have already been resolved. Refine- 
ments at the "hi-fi" stage should focus on perfecting the 
details. 

60 In the later stages of development, usability laboratories 
can be extremely helpful for evaluating system design. 
Usability labs, which can be stationery or portable, rely on 
videotape and screen capture methods to record how users 
interact with prototype systems. Within a few hours of 

65 testing, lab administrators can create a high fights videotape 
of problems that users encountered. These tapes can be used 
immediately by developers and project managers to modify 
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the hi-fi prototype as required. The average usability test Data Name Rationalization 

results in 70 to 100 specific recommendations for improve- Data name rationalization tools extract information on 

ment. variable usage and naming, and show relationships between 

Remote testing, or telecasting, is an online variation of the variables. Based on these relationships and user input, these 

usability lab. This still-emerging method relies on computer 5 tools can then apply uniform naming standards throughout 

networks to conduct system evaluations. Remote testing system. 

enables developers to test a large number of users efiScienUy Packaged Component Integration (232) 

and without incurring travel expenses. Packaged components are generally third party compo- 

Reverse Engineenng (230) ^^^^ ^^^^ provide ready-made business logic that is cus- 

Reverse engineenng tools are used to capture specific, ^^^^^^^ ^^^^^^ ^^^^ 

relevant ftmctional and design information from a legacy ^.^.^^^ functionality (for example, 

system for use ma new, client/server system or to restructure ^ ^ ^ L^-^tiT ^ l 

the existing system for improved performance and mainte- ^oiksheel or chartmg GUI componenis) to components that 

nance handle a significant portion of the application architecture 

Interactive Navigation (^o^ example, data access components and firewalls). The 

Developers use interactive navigation tools to identify 15 advantage of using such components is that they have 

requirements for a new system from the functionality and already been coded, tested, optimized, and documented, 

design of a legacy system. Hiese tools enable the developer The fact that these components come from third -party 

to interactively and graphically navigate the legacy system, software houses does not always guarantee their quality. In 

determining the system's characteristics such as system order to minimize the dependency of the final system on 

structure, module flow, flow control, calling patterns, 20 these components (thus reducing the impact of possible 

complexity, and data and variable usage. An alternate form changes within the libraries), it is recommended that wrap- 

of presentation is through reports. These provide cross- pers are written to enclose any third -party components. This 

reference listings or graphical representations of control or way, if any changes are made to the internals of the 

data flows. components, only the wrappers would be affected, allowing 

Graphical Representation 25 the application and architecture code to remain unchanged. 

Graphical representation tools arc used to display impor- Product Considerations 

tant system information in a form, which is easier to a) Does the component require significant customization? 

assimilate. These tools may, for example, produce structure When selecting components, it is important to get as close 

charts, database schema diagrams, and data layouts. They a match as possible to the functionality that is required, 

can also print matrices that indicate relationships between 30 b) Will the vendor guarantee required functional enhance- 

modules and files or between jobs and programs. ments? 

Extraction If functionafity is missing firom a component that cannot 

An extraction tool, in conjunction with a repository popu- be added using the standard customization tools provided, it 

lation tool, enables the developer to reuse selected portions is vital to get a vendor guarantee that the enhancements will 

of a legacy system. The extraction tool can typically read 35 be made, and to agree on a deadline for these enhancements, 

and extract iofonnation from source code, screens, reports, c) Will the vendor guarantee consistency of all interfaces 

and the database. The most common information extracted across fiiture releases? 

from a legacy system, however, is the data: record/table The biggest danger in using packaged components is that 

structure, indexes, and data element definitions. the vendor will make changes to the component interfaces. 

In component-based architectures, as systems are often 40 When selecting packaged components make sure the vendor 
built on top of legacy databases, some extraction tools allow guarantees backwards compatibility of all the existing inter- 
generation of an object model from the legacy database data faces provided by the component. If this is not the case, it 
model (DDL). By understanding the E-R diagram repre- will entail much reworking of the application code in order 
sented by the database, it is easier to create an efiScient to be able to take advantage of (potentially important) 
persistence framework which isolates business components 45 upgrades to the component. 

from a direct access to relational databases. Caution is d) What are the performance implications of using a pack- 
required, however, as the resulting model is at best only aged component? 

partial, as an object model has dynamic aspects to it as well Components are often developed with a preferred plat- 
as static relationships, and may not correctly reflect the form in mind. Components optimized for one platform may 
analysis performed in the problem domain. 50 have severe performance problems on others. If perfor- 
Repository Population mance is a factor (and it nearly always is) ensure that 
The repository population tool is used to load the infor- components are designed specifically for the platform of the 
mation from the extraction tool into the development reposi- target system. 

tory. These tools convert the information from the legacy e) Does the component provide standard or proprietary 

system into the syntax of the development tools repository. 55 interfaces? 

The extent of the information loaded into the repository is a When choosing between packaged components, always 

function of the Information Model of the development tool choose standard interfaces over proprietary ones. It will 

repository. Information that is not represented in the devel- always be easier to customize and interface a component 

opment tool repository cannot be loaded into the repository. whose language is known to the development team, rather 

Restructuring 60 than one which requires developers to leara a new propri- 

Restructuring tools are not analysis tools like the previous etary language, 

categories of reverse engineering tools, but design and Customization 

construction tools. They enable the developer to rebuild a Packaged components usually do not provide the exact 

legacy system, rather than replace it. Examples of this type funaionality that is required of the target system because 

of process include restructuring spaghetti code with struc- 65 they are created by third parties. They may have to be 

tured code, replacing GOTO's, streamlining the module configured in order to behave in the desired fashion. The 

calling structure, and identifying and eliminating dead code. majority of packaged components allow one of two methods 
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of customization — either by using standard construction The construction tools selected must be able to support 

tools (such as an editor and a C compiler), or by using the target platform(s) of the system to be developed, 

proprietary toolkits provided by the vendor. Source Code Editor 

, , * -J A source code editor is used to enter and edit source code 

Implementation Considerations r .l r i •* • r • i Aor^n 

^ 5 for the appUcation. Complexity vanes from simple ASCII 

a) What level of support is provided by the component text editors to fully integrated editors such as those provided 

vendor? by Integrated Development Environments. Typically 

It is vital that the vendor provides an appropriate level of however, they are linked with a debugger so that coding 

support for the component such as documentation, telephone ^"ors which are identified during compilation can be more 

support, remote support, training, and onsite support. It lO ^^^y corrected, since the error and the source code gener- 

might also be necessary to include vendor developers on the ^^"^g ^^"^^ ^^^^^ simultaneously. 

Apphcation team. This is especially important where com- Other features include: 

ponent customization reUes on proprietary toolkits. Dynamic syntax checking, improving productivity by 

Construction (234) detecting errors as they are made, rather than at compile 

Construction tools are used to program or build the „ uu* * ii i-^nr 

v. J j j Color codmg, which automatically applies different colors 

application: client and server source code, windows, reports, . . . j j- ^ : w 

[t ^ , t -^u . rir 1 n r J to text depend mg OD its type or context (e.g. commc nts, 

and database. Alone with the onset or Visual Programmine, -.i . j i- . . 

,v * jv- 1 c r * . 1 L L variables, reserved words etc.), thus making the code 

the more traditional form of construction tools have been readable 
superceded by Integrated Development Environments . , . - . - 

(IDEs) which take all the basic components required for Automatic layout, which mdents code depending on its 
construction, and integrate them into a single system. logical teyel (e.g. loops, coaditionals etc.) 

Although IDEs are now the preferred tools for most , ^n the whole these features will help ensure that code 

construction, the components that make up these tools developed by the team is following project standards as 

remain the same-Source Code Editor, Compiler/Linker/ "PP''^'^ '° mdivulual programmmg styles, 
interpreter. Generation Tools and Debugging Tools. ^ Implementation ConsideraUons 

, ^ , _ , . . . „ - , . . , a) Web-based development 

Visual Programmmg tools, imtially associated with the ^ ^^^^ Web-based appHcations to com- 

rapid development of the chent-side of client/server bine multiple components (such as HTML, Javascript, Java 
applications, have now matured and expanded their domain j^^^^ ^^^ ^^ numerous source code editors may 

to cover entire client/server development (e.g. Visual C++) 3, t,e required for the development of any single web applica- 
and Netoentnc development (e.g. visual Java IDEs). ^ =*- 

IMPORTANT: While IDEs provide the basic components Product Considerations 

for construction, not all the functionality offered by the a) How weU integrated is the editor with other tools in the 

components listed here is provided (for example IDEs do not development environment? 

generally provide Help text generation or DDL generation). 35 The level of integration with the rest of the environment 

IDEs can usually be customized in a way that other tools is an important consideration when selecting a source code 

(Version Control, Generation, Repository Access etc.) can cdiiOL Most editors now come as part of an IDE, and are 

be integrated. It is necessary to plan time for this upfront. It therefore fully integrated. 

should not be left to the developers to do this individuaUy. 5) Does the editor support multiple languages? 

In addition to the standard construction components, a new ^ Some IDEs provide support for many languages using the 

set of utilities exist which can help increase the quality of game interface (for example, MS Developer Studio supports 

code generated by developers. QA Utilities verify the quality c, C++, Java, Fortran). This has the advantage of providing 

of constructed code, and its conformance to standards set the user with a common approach to coding, regardless of 

down for the development environment. language being used. 

It is important to ensure that developers use tools that are 45 c) What features are provided by the editor? 
standard to the development environment. Now that Internet As mentioned in the component description, many fea- 

access is a standard facility for developers, there may be the tures may be provided by the editor, which can save time and 

tendency for people to download their own preferred took, improve code quality. A feature-rich editor is therefore often 

or upgrades to standard tools. This not only affects the worth the investment, 
management of the development environment, but could 50 d) Is the product easy to learn and use? 
easQy result in the generation of code that is incompatible The source code editor should be easy to use with little or 

with the rest of the code in the development system (for no training required. 

example, consider the effect of developers on the same team e) Is an acceptable source code editor already provided by 

using tools which employ different version of the JDK). the operating system or other tools in the development 
Product Considerations ^5 environment? 

a) What size is the development team? . ^""f Development tools and operating systems already 

,rx»- ^ 1 . . . . . J mclude a source code editor. These source code editors are 

• . f . first developed, Oiey were targeted at ^^^^ ■ ^j,^^ 

individual developers. This means that suppor for temti ^ ^^^^ application code? 

development >s still not fully mature m tbe majority of IDEs, ^ gome source code editors may not have the ability to 

although some are closely integrated with third-party cot- 1^^^,^ extremely lai^e files whUe other tools are buUt 

figuration management packages When selectmg an IDE it specifically for that purpose, 

is miportant to ensure that team development is sufficiendy Compiler/Linker/Interpreter 

catered for jjij^ component is responsible for taking raw code 

b) On what platform is the system expected to run? (usually in ASCII format) and creating the necessary object, 

c) Is the target system expected to run on multiple plat- library, byte-code, or executable files that become compo- 
forms? nents of the final system. The actual tools required depend 
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00 the development language, but always consist of one or 
a combination of the following components: 
Compiler 

Linker (preferably incremental — the linker can substitute 
a new version of a single module rather than having to 
re -link the entire program) 
Interpreter, which can speed up the test/correct cycle by 

eliminating the compile and link steps 
In the majority of Integrated Development Environments, 
the Compiler, Linker and/or Interpreter are included as an 
integral part of the system. In addition, the management of 
compilation and linking is automated using MAKE utilities 
which understand the dependencies between modules in the 
system. This allows the system to trigger all necessary 
re-compilation and re-linking when a module io the system 
is changed, thus avoiding the time consuming task of 
re-compiling and re-linking the entire system. 
Product Considerations 

a) Is the tool easy to use? 

The tool should be relatively easy to use in order to reduce 
the learning curve. 

b) Does the tool support the platform in the development 
environment? 

The compiler/linker/interpreter tool must be compatible 
with all the platforms upon which the application is being 
developed. Besides compatibility, tool performance may be 
platform dependent. 
Source Code Debugger 

A source code debugger is a tool used to unit test a 
program. This tool provides information about the activity of 
programs and systems, enabling automatic analysis and 
diagramming, assisted code tracing, editing capabilities, and 
automatic documentation. The debugger allows the devel- 
oper to enter program break points and step through a 
program, tracking the progress of execution and identifying 
errors interactively. It is typically used in conjunction with 
the source code editor so that coding errors identified can be 
more easily corrected, since the error and the source code 
generating the error can be viewed simultaneously. 

Symbolic source code enables easier identification of 
where errors occur. Preferably, the debugger should be 
flexible enough to work with any combination of compiled 
modules and source modules. In addition, the debugger 
should be able to handle calls to the database and to other 
modules. 

Product Considerations 

a) What testing team factors should be considered when 
using a source code debugging tool? 

Communication between development team and testing 
team: 

A code analysis tool can help the testing team detect 
unreported changes in the application code, and therefore 
help alleviate possible bad communications between the 
development and testing teams. Thus, bad communications 
between teams will still influence positively the decision to 
use code analysis tools. 
Generation 

Generation tools include: 

Shell generation 

Make file generation 

Window/page generation 

Data Definition Language (DDL) generation 

Data Manipulation Language (DML) generation 

Code generation 

Include file generation 
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Help text/module description generation 
Trace code generation 

Shell generation is the process of generating a starting 
point for programming. Shell generation is typically 
5 repository-based but can also be based on interaction with 
the programmer, where the generation utitity requests key 
information about the program, and generates a starting 
point as a result of this. Key information (whether obtained 
from the repository or through a dialog with the 
10 programmer) may include: 

Data base tables accessed 

Methods and attributes defined (for objects) 

Interface information 

Based on this information, the generator selects the appro- 
15 priate include files and creates skeleton code which may be 
used as a template for the programmer. This template may 
also include audit history for the module and standard code 
such as error handling. 

Make file generation is integrated into the majority of 
20 IDEs 

Window/page generation (which is an integral component 
of Visual programming tools) allows the developer to rap- 
idly design windows and pages using a point and click 
graphical interface. The relevant source code is subse- 

25 quently generated from these designs. 

The generation of DDL and DML is often hidden from the 
developer by using data access functions or objects, pro- 
vided by a large proportion of IDEs (e.g. MFC, JDK) Help 
text and module description generation (not usually pro- 

30 vided by IDEs) analyzes developer's raw code (including 
comments) and creates descriptions which may be used by 
developers to understand the contents of modules or objects. 
This is particularly useful for component-based 
development, where methods and attributes of objects may 

35 be automatically documented. 

Trace code generation allows the insertion of traces into 
raw code in order to aid debugging. 
Implementation Considerations 

a) Does the project want to isolate developers from the 
40 technical environment as much as possible? 

b) Are there a large number of developers which makes it 
difficult to enforce standards and consistency among devel- 
opers? 

Generators are typically used to enforce and maintain 
45 consistency throughout an application. The main benefit is a 
reduction in training. In addition,^ the code generated will 
automatically be checked for errors, shielding the develop- 
ers from many complexities of the technical environment. 

c) Are there a large number of developers or a large amount 
50 of code? 

d) Can significant time be saved by creating generators to 
generate code for reuse and regenerated code to propagate 
changes? 

Generators are used to leverage the powers of code reuse 
55 and code regeneration. The ability to reuse code reduces 
both the time and resources required on a project. Code 
regeneration eases maintenance issues by propagating 
changes throughout multiple sections of code. 
Product Considerations 
60 a) Can the generation tool provide code which meets per- 
formance requirements? 

The code/applications generated by the tools vary in 
performance. Optimized code usuaUy results in faster run 
times. It is important to identify the high priority compo- 
65 nents that wfll benefit most from the tool. 

b) Should the engagement team build a custom generation 
tool or purchase an existing one? 
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The decision to custom build or to buy available case tools This requirement for more attractive user interfaces has 

must be determined by the development team. Most gen- triggered the evolution of media-rich applications, the devel- 

erators are usually custom built because often the technical opment of which requires new tools and processes, and 

environment and architecmre have custom components that brings with it a whole new set of issues. 

cannot be handled by a package generator. Associated with 5 Media content can be broken down into three major media 

custom building arc the issues of added cost and develop- types, each with its own set of tools: 

ment time, but performance can be closely monitored and 2D/3D Images/Animation 

changes performed on the spot. Video 

c) Does the generation tool support the development and Audio 

execution platforms? lO ^nnrr^i /a • 

~ , r , _ , J 1 .r 2D/3/D Images/Animation 

The tool must support the current or proposed platform. t> i . u ji • r • ^ 

^ Ti l - Jools to handle these images range from simple pamt 



QA Utilities 



packages to highly complex multi-layered animation graph- 



QAUtditiesverify the quality of completed code, and that - ^, ^ ^ ♦ ^ u *u * i u 

. r • 1 • 1 J J r™_ ICS packages. The images created by these tools may be 

It conforms to project and international standards. These • i u ~i /u*. \ * u i u -^u *u • 

- , . , . . r ,. pixel-based (bitmaps) or vector-based, each with their own 
types or tools include the lollowing: 15 V, 

^ advantages. 

Code Analysis-Code analysis provides the objective pj^el-based tools (traditional graphics and image process- 

information and metrics needed to monitor and * i \ - a -t--i-* - n - 

J, • / . mg tools) offer more image flexibility especially m 

unprove code quality and mamtenance (e.s. static , r t j*- ^i^^- l^ j 

\ j j \ terms of color gradation and shading, but produce 

analyzer, documentor, auditor). t i i ci -ru e * * *u r e. ^ 

' ' ^ relatively large files. This format is therefore useful 

Code Error Checking— Checks code for common errors ^t^^re the use of high quality textured images, or highly 

(e.g. syntax errors, uninitiaUzed and badly assigned colored images is important, but where file storage and 

variables, unused variables) transmission is not an issue (where the media content is 

Code Beautification — Re-formats code in order to make it local to the client application, such as in a kiosk). 

easier to read and maintain. Vector-based tools (where the image is defined by formu- 

UNIX Portability Checking — Checks compliance with lae rather than pixel position) offer much smaller file 

basic portability standards — particularly with program- sizes, and dynamic image re-sizing, while producing 

ming standards that ensure portability across UNIX excellent print quality, but cannot easily handle shading 

platforms (e.g. POSIX compliance and OS/2-to- and color gradation. This format is more appropriate 

Windows portability). where file size is an issue (web pages). 

100% Pure Java Checking— Checks that Java code con- Video 

forms to the 100% Pure Java standard. The high cost and complexity of video production 

Code/Object Libraries equipment, along with the skills required to manage the 

Code and Object libraries provide the developer with process of video production mean that it is usually out- 
ready- made components (such as GUI components or 35 sourced to a third party. It is important however that the 

simple utilities), which may be integrated into architecture personnel charged with creating video content are an inte- 

or application code. The advantage of using such compo- gral part of the Application team, 

nents is that they have already been coded, tested, optimized, Audio 

and documented. The tools required for creating audio content depend on 
Code and Object libraries may be differentiated from ^ the quality required, and whether or not the content is 

packaged components in two ways: original. For 'sound bites'or pre-recorded audio, simple 
They contain little or no business logic desktop audio editing applications are adequate. For high- 
Source code is usually provided (as opposed to the 'black ^^^^^^y original content, a professional recording studio is 
box' component approach) recommended. Again, if third parties are involved, it is 
That these libraries come from third-party software 45 important that they are fuUy integrated into the team. 

houses does not always guarantee their quality. In order ^"^^o, it is possible to purchase 

minimize the dependency of the final system on these re-usable content fi-om agencies, usually deUvered in the 

components (thus reducing the impact of possible changes ^^^^ CD-ROMs. 

within the Ubraries), it is recommended that wrappers are NOTE: Tools required to store and manage media content 
written to enclose any third-party code. This way, if any 50 (^°^ storage foraaats) arc discussed in Tools— Information 

changes are made to the libraries, only the wrappers would Management— Media Content Management 
be impacted, allowing the application and architecture code 

Test (236) 

to remain unchanged Testing applications (client/server or Netcentric) remains 

Implementation Considerations ^ complex task because of the large number of integrated 
a) Does the object/Ubrary really need to be wrapped? 55 components involved (for example, multiplatform cfients. 

It may not always be prudent to wrap all third party multiplatform servers, multitiered applications, 
objects/code that are to be used on a project. Sometimes the communications, distributed processing, and data), which, 
cost involved may outweigh the value of wrapping an m turn, results in a largp number and vanety of Testing tools, 
object/code. As objects/code become more complex, with ^^r any large scale testing effort, it is vital to have a 
more functions/interfaces, then the value of wrapping them 60 repository (see Tools— Information Management- 
becomes more tangible. Repository Management) that is capable of managing the 
Media Content Creation ^^^^ required by each of the test subcomponents. The 

As systems become increasingly user-facing, it is impor- repository should manage the following entities: 

tant to design user interfaces that are not only functional, but Test conditions 
also engaging and informative. This is especially true of 65 Test cycles 

Internet and kiosk-based systems, where users have a note- System Investigation Requests (SIRs), triggered by a 

riously short concentration span. deviation of actual results from those expected 
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Test data ration management tool (easier control over all system 

Requirements configurations and component versions), and a test plan 

Within the repository, the following relationships between management tool (easier control over all test cycles, 

entities must also be managed: subcycles, their execution statuses, and so on). 

Test cycle and the system component to which it refers ^ engagement factors affect the use of Test Data 

^ . . . ... Management tools? 

Test condition and the test cycle it belongs to ^^j^ ^^-^^ engagement 

Requirement and the test condition that tests that require- jp general, management and planning tools help better 

™ent address the engagement risks. A high risk rating for the 

These relationships make it possible to analyze efiSciendy lo engagement will affect positively the decision to use tools 

the impacts of change and to document the state of system such as test planning. Test Data Management, problem 

test. For example, the number of outstanding SlRs per cycle management, and configuration management, 

can easily be provided based on these relationships. Criticality of the engagement 

In some cases, the mentioned entities and relationships [□ general, management and planning tools help better 

cannot be managed within the repository, and may have to ^5 manage the engagement and ensure the timely delivery of a 

be modeled outside the repository (for example, in a team- quality system. Therefore, dealing with a highly critical 

ware database). In this case, the link between the repository engagement will most likely affect positively the decision to 

and the external tools must be provided by a judiciously use tools such as test planning. Test Data Management, 

chosen set of procedures and custom integration tools. problem management, and configuration management. 

Component-based development may have an impact on 20 Test Data Manipulation 
the way in which testing should be perfonmed. Test Data Manipulation tools are used to create original 

A number of firm initiatives have conducted considerable test data and, sometimes, to modify existing test data. Such 

research into the field of testing: modifications may be needed to process a change in the 

Year 2000 Testing Contacts and KX Resources database schema and to correct intermediate results in order 

The Technology Library contains further information ^5 to complete a test cycle. Some test data manipulation tools 

including tool evaluations, practice aids, and newslet- generate test data very effectively, 

ters Test Planning 

Integrated Testing Environment Job Aid ^ ^est Plan consists of several components: 

Product Considerations Test schedule 

a) When should vendor tools be used in the testing process? Test execution tracking 

^^ndor tools are more appropriate when the requirements Test cycles 

are totally dependent on the software development platform. jg^t scripts 

Moreover, when the technology evolves too quickly, it jg^^ conditions 

requires a software organization to handle the changes. ^^^^ condition generation 

Test Data Management ^^^^ ^ 

Test Data Management tools allow developers to create ^ 
and maintain input data and expected results associated with Expected results 

a test plan. They include test data and archiving tools that Planning defimtion and maintenance tools define and 

assist in switching between cycles and repeating a cycle maintain the relationship between components of a Test 

based on the original data created for that cycle. rlan. 

Test Data Management functionality may be provided by Implementation ConsideraUons 
the following tools* guidelines should be followed when assembly 

— , . , „ , , testing the technology architecture? 

Test data generauon ^ols-ii^aUy generate test data by ^^^^ ^^^^^ ^^^^^ ^^^^^ technology architecture 

permutation of values of fields, either randomly or ^ ^^^^ ^jj^^ guideUnes provided by the a job aid for 

systematicaUy. technology architecture assembly testing. 

Test design repository tools^faciUtate structured design b) What guidelines should be EoUowed when creating test 

and maintenance of test cases. They help the developer scripts? 

find existing test cases, cycles, and scripts that may be when preparing to test system components, scripts can be 

appropriate for reuse. 50 used to verify that the system design specifications are 

Data management tools — provide backup and restore properly implemented. A job aid provides guidelines for 

facilities for data. They also provide configuration creating product test scripts. 

management for multiple versions of data, maintaining c) What guidelines should be followed when creating test 

consistency among versions of test data, cases for the component test? 
Implementation Considerations 55 When preparing component test data, a checklist helps 

a) What guidelines should be followed when creating com- ensure that all cases are thought up so that component testing 

poncnt and assembly test data? is complete. 

To minimize testing errors when creating component and d) What components interface with the Test Planning corn- 
assembly test data, follow the guidelines provided by the AC ponent? 

Methods job aid for quality test data. 60 The following components interface with the Test Plan- 
Product Considerations ning component: Tools — System Building — Test — Test 
a) What testing team factors should be considered when execution. This interface relates to the actual Test Planning 
using a Test Data Management tool? scripts for an automated script playback capability. The 
Size of the testing team scripting tool can be call directly from the Test Planning 
The larger the testing team, the more benefits will be 65 tool, which runs it or loads it to the target platform. More 
derived from using a Test Data Management tool (easier generally, all scripts, and actual results should be linked to 
control over the test data for the various testers), a configu- the cycles. 
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Tools — System Building — Test — ^Test Data Management. perforaning of each test stage. Each test model is stored in a 

Before beginning the cycle, the transfer, load, and refresh of central repository accessible by all team members, 

lest data can be run from the Test Planning tool. Any test model data must be manually entered in the 

Tools^Information Management— Repository Manage- system or copied from a previously entered test model, 

ment. Each conversation, dialog, or executable tested in a 5 Multiple test models can be accessed or viewed at one 
cycle can be cross-referenced so that it is possible to know 

from the design where a functionality is tested. addition, the TPMS provides the capability to research 

Tools-Configuration Management. Each conversation, previously entered test elements through online queries, 

dialog, or executable tested in a cycle can be cross refer- ^ reportmg option is planned to produce metncs and 

enced so that it is possible to know from the design where lO management type reports. 

a functionality is tested. ^) What testing team factors should be considered when 

e) What is a repeatable test model? ^^ing a Test Planning tool? 

f) What is the importance of a test database? ^ize of the testmg team 

g) What is the team member retention with a repeatable test? ^^^^^ ^^^trng team, the more benefits wiU be 

h) How does a repeatable test model affect testing automa- 15 ^^^^^ ^^^"^ ^"^8 ^ Test Data Management tool (easier 
j^Qjj7 control over the test data for the various testers), a Configu- 

ThefoUowing is an overview of the repeatable test model nation Management tool (easier control over all system 

as documented by the Reinventing Testing Project (RTP). configurations and component versions), and a Test Plan 

Arepeatable test model consists of tests that can be easily Management tool (easier control over all test cycles, 

executed by staff who have little or no experience of the 20 subcycles, their operating statuses, and so on), 

application being tested. A repeatable test script provides the ^) What engagement factors affect the use of Test Planning 

detailed steps necessary to test the functionality. In addition, tools? 

the script provides the tester with detailed expected results Rating of the Engagement 

to verify the operation of the test script. 1° general, management and planning tools help better 

Id order to plan detailed script steps and expected results, 25 address the engagement risks. A high risk rating for the 

it is necessary to know the test data, A large portion of the engagement will affect positively the decision to use tools 

test data will typically be contained in test databases. These such as Test Planning, test data management, problem 

databases are caUed baseline databases, and are critical for management, and configuration management, 

a repeatable test model to exist. Baseline databases can be CriticaHty of the Engagement 

developed automaticaUy (through execution of online activ- 30 ^° general, management and plannmg tools help better 

ity in the system), manuaUy (through test data manipulation manage the engagement and ensure the timely deUvery of a 

tools), extracted from production databases, and so on. Once ^^l^*y system. Therefore, dealing with a highly critical 

the baseUne databases are selected and created, the repeat- engagement will most likely affect positively the decision to 

able test model can be developed. As the test model is based "^e tools such as Test Planning, test data management, 

upon these databases, the impact on the test model of any 35 Problem management, and configuration management, 

changes to the baseline databases must be analyzed. ^) ^^^^ application factors should be considered when using 

With a repeatable test model, most of the team members' ^ Planning tool? 

knowledge is captured in the tests. Retention of team mem- Starting point of automation in the development life cycle 

bers is therefore far less critical than with a non-repeatable *^sting process is to include the use of a test plan 

test model, and expected costs of training new team mem- 40 management tool, test model components may be more 

bers are reduced easily reused across test stages resulting in time and cost 

If the application does not change, repeating the tests savings during Test Planning and preparation. This obvi- 

yields the same results every time, given the same baseline ^^^y ^ positive influence on the decision to use the test 

databases. To remain repeatable, a test model must be P^a° management tool, 

maintained to reflect changes made to the application (fixes, 45 Execution 

isolated enhancements, new releases, and so on). 'Test Execution tools support and automate the conduct of 

To ensure the quality of the application as weU as testing ^y^^^,^ ^^^^ Execution support includes the tools 

efficiency and effectiveness over time, the tests contained in required to: 

the test model must be repeatable. Automation facilitates the Extract input data and expected results from the reposi- 

engagement's ability to execute a repeatable test model. The 50 lory 

decision to automate the test execution only affects whether Load this data into the appropriate Test Execution tools 

the tests will be repeated manually or automatically. Automate the test 

Automating the execution of a non-repeatable test model Such tools include dynamic analyzers and execution logs, 
is a waste of resources, as the test tool will not be able to The Test Execution platform may differ from the deve lop- 
re-execute the tests automatically or perform full regression 55 ment platform if development is conducted in one environ- 
tests with little effort. Little or no benefits will be achieved ment (for example, Windows NT workstations) and 
from automation. deployed on a different environment (UNIX workstations). 
Product Considerations A typical Test Execution tool supports test scripting and 

a) Has RTP (Reinventing Testing Project) developed a test playback. These tools program or record the mnning of a test 
plan management system? 60 plan in an online environment by capturing key stroke 

b) What tools can be used for problem tracking? sequences, mouse clicks, and other actions. They then record 
The RTP Tools Development team has documented their them in a script. Once the script is programmed or recorded, 

evaluation summaries of the internal test plan management it can run repeatedly on the same application, effectively 

system. The following is a brief description of the product. emulating the user. While defining the script takes some 

The Test Plan Management System is an online GUI 65 time, it saves tremendous effort when cycles must be re-run, 

application that is used to faciUtate the creation and main- particularly after relatively small changes (for example, the 

tenance of test models and to support the planning and format of an output field is modified). When the application 
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is modified, the script can be updated directly without 1.1. Testing team factors to be considered include: 

re-entering long sequences of user input. This makes it Willingness and ability to maintain the test model 

easier to prepare for regression testing. Scripts may also be Communication between development team and testing 

used for stress testing, where a single machine can run team 

scripts simultaneously, emulating large numbers of users. 5 Control over the test environment 

Implementation Considerations Acceptance of automation (attitude toward change) 

a) What development approach factors should be considered Experience with test automation 

when automating Test Execution? Experience with the testing process used on the engage- 
Reinventing Testing Project (RTP) has identified the fol- ment 
lowing factors that either contribute to or take away from the Experience with specific testing tools 
successful implementation of an automated Test Execution Anticipated learning curve with automated testing tools 
tool. Further detail is available through RTF's Test Auto- Experience with the technology used on the engagement 
mation Strategy — Version 1.1. The type of system develop- Size of the testing team 
ment approach to be considered is: Performance Management 

Maturity of the testing process , Performance Management tools support application per- 

formance testmg. Owmg to the large number of components 

Number of technical platforms njodem systems, performance modeling can be a complex 

b) What testing tool factors should be considered when task and requires tools to efifectively manage the process, 
automating Test Execution? These tools monitor the real-time execution and pcrfor- 

RTP has identified the following factors that will either 20 mance of software. They help to maximize transactions and 

contribute to or take away from the successful implemen- response time to the end user. They are also useful in 

tation of an automated Test Execution tool. Further detail is identifying potential bottlenecks or processing anomalies, 

available through RTF's Test Automation Strategy — Version 1° case of Internet-based applications, as the Internet 

1.1. Testing tool factors to be considered include: ^ » controlled environment, performance management 

^ ^ . . . ' V 2'i tools can only measure performance within the domain of 

Cost of testing tools (including traimng and support) controlled environment (up to the Internet Service 

Cost of test model maintenance (including test data) Provider). However, in the case of intranet-based systems. 

Testing tool ability to work with GUI application builder where the environment is controlled from end-to-end, Pcr- 

Vendor support capability formance Management may be performed across the entire 

Proximity of vendor support personnel to the project site Emulation 

AvailabiUty of tool support person on the testing team Emulation tools emulate components that are part of the 

c) What engagement factors should be considered when target environment but are not in the development environ- 
automating Test Execution? ment. These emulation tools include: 

RTP has identified the following factors that will either Target platform architecture components, including both 

contribute to or take away from the successful implemen- custom infrastructure and system software products 

tation of an automated Test Execution tool. Further detail is such as an X-window emulator on a PC to access a 

available through RTF's Test Automation Strategy — Version Unix platform 

l.L Engagement factors to be considered include: ^^^^^^ ^^-^^^ emulate subroutines in a minimal fashion. 

Fixed fee engagement 40 Harnesses and drivers, which call up a module and 

Risk rating of the engagement emulate the context in which the module will be called 

Criticality of the engagement ^ production environment. 

n- 1 c . . . • Test Result Comparison 

Risk of not automatmg testing ^^^^^ Comparison tools are utUities used to compare 

d) What application factors should be considered when ^5 expected and actual results. These tools oudine the differ- 
automatmg Test ExecuUon? between actual and expected results by comparing 

RTF has identified the foUowing factors that will either files and databases. Most of these tools offer functionality 

contribute to or take away from the successful implemen- such as byte-by-byte comparison of files and the ability to 

tation of an automated Test Execution tool. Application mask certain fields such as date and time, 

factors to be considered include: 50 Test Coverage Measurement 

Application life expectancy T^st Coverage Measurement tools are used to analyze 

Number of planned releases '^^'''^ ^^^^ "^^^^^^ ^^^S the test. Cov- 

r * ■ r . erage analyzing tools are active during program operation 

Use of apphcauon software packages p^^^^^^ comprehensive information about how many 

Frequency of upgrades in appHcation software, system 55 times each logic path within the program is run. This Test 

software, and hardware Management and Quality Management tool ensures that all 

Stability of the application components of an application are tested, and its use is a vital 

Starting point of automation in the development life cycle ^nd often overiooked component of the test process. 

Scope of the test automation SIR Management ^ , ^ . . 

^ c . 60 SIR Management Tools help track each system mvesti- 

Number of passes per test cycle ^^^-^^ ^^^^^^^ ^^^^ p^^^^l^^ ^^^^^^.^^ ^^^^^^ documenta- 

e) What testing team factors should be considered when tion resolution. 

automating Test Execution? Operations Architecture Framework (1300) 

RTP has identified the following factors that will either Operations Architecture 

contribute to or take away from the successful implemen- 65 As shown in FIG. 13, the Operations Architecture is a 

tation of an automated Test Execution tool. Further detail is combination of tools, support services, procedures, and 

available through RTF's Test Automation Strategy — Version controls required to keep a production system up and 
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running eflSciently. Unlike the Execution and Development What are the data sharing requirements with other func- 

Architectures, its primary users are the system administra- tions? 

tors and the production support personnel. Integration between functions will either require a tool 

The following databases provide information on the capable of supporting both functions, or hooks between 

Operations Architecture and list requirements and current 5 tools. 

tools solutions for the managing of the various Operations what arc the expected data/transaction volumes, and how 

Architecture areas. All areas of the Operations Architecture ^juch historical data will be required? 

have the appropriate MODE sub-functions listed, along with y^y^^^ ^^^^^ historical, will have 

requirements for management solutions and current tools ^„ ^ ^^^^ ^ ^^^^^^ ^-^ 

d^at assist and auton^ate management solutions. platform/protciol constraints exist? 

Cautions and Caveats ^, ^ , . i u *u * n 

Unlike the Application and Execution Architectures, ^^^^^onns and protocols are central both to the overall 

every fimctioa of the Operations Architecture must be ^Pf.'^.^^h ^ ^^^^^^^^^ ^^^^ ^PP°^ 

reviewed. All components of the Operations Architecture are individual functions. 

integral to the successful management of a distributed Is the intention to use tools or to custom develop some or all 

environment- Any processes, procedures, or tools developed of the functions? 

or chosen as an operational management solution for a Th^ choice of tools in the marketplace is increasing, but 

specific operational area must be able to integrate with any custom development may still be required. This decision 

existing or planned process, procedure, tool solutions for will impact how the function is established initially as well 

other Operations Architecture areas. as its ongoing support and maintenance. 

While the tools data and suite information was current and 20 Will existing data/databases be used, or will data be built 

accurate at the time of publication of this document, there is from scratch? 

no guarantee that that information is still accurate, or that the Many of the functions may already exist within the clients 
vendor is still in business. It is imperative that the following environment. As such, data which is necessary for support- 
actions are taken when choosing a tool-based solution: ing the system may already exist. If so, it must be deter- 

determine that the vendor is stUl a viable candidate (i.e. 25 mined whether or not the existing data can be used, either in 

still in business, good recent product support track record) its original or a converted state. 

verify the version of the tool to be installed will still General Product Selection Considerations 

provide the management solution required It is important to note that there may be requirements 

verify the tool(s) will integrate with existing tool(s) which cannot be met by any tools. In this case, in-house 

verify the tool(s) will integrate with other planned tool(s) 30 development may be an alternative. This approach is likely 

acquisition(s). to be more expensive, however, and more difScult to support 

General Implementation Considerations the long term, and thus should usually be avoided if possible. 

Some key design decisions are specific to the design of Were possible, the tool with the closest match should be 

certain functions, while others apply more generically across purchased, and customized to meet the necessary require- 

every function. This section presents the generic key design 35 ments. 

questions. Key design decisions that relate specifically to a Some additional considerations are outlined below: 

function are presented in each of the subsequent functional Central vs. Distributed Control 

grouping chapters. The answer to this question may limit the selection of 

The following generic decisions impact need for specific tools as not all tools are capable of controlling functions 

components: 40 remotely. If control is centralized, technical expertise at 

When and how frequently, does the function need to be distributed sites will not be necessary. This may, however, 

performed? mean that a more complex, expensive tool is required. 

The timing and frequency of each function may have an If control is distributed, technical expertise will be needed 

effect on its staffing, the tool(s) required, the capacity of at remote sites, and there is the potential for problems with 

systems aiKi networks needed to support the tools. 45 the interfaces between tools. 

Who will be performing the function? Platform Constraints 

Responsibilities need to be defined for each function, as Systems-based tools (e.g., for monitoring or control 

the set up tasks will differ dramatically depending on purposes) will clearly be platform dependent. Functional 

whether the function is to be performed in-house or out- tools (e.g., to support Incident Management or Change 

sourced. In addition, the individuals who wiU be performing 50 Control), however, can run independently from the systems 

the function should be involved in the design of how the tools and may only need to run on a limited number of 

function will be performed. systems. 

Will the function be centralized or distributed? Integration with other Functions 

Central control will mean a stronger focus on remote Integration between some of the functions is highly 

management, with skills focused in one place, whereas 55 desirable. Integrated toolsets offer integrated functionality 

distributed control will mean skills will need to be more across a number of functions, thus simplifying the interfaces 

widely dispersed. Distributed functions may require less between them (e.g., data will automatically be consistent 

powerful tools due to their placement. across functions). Purchase of such tools will help reduce 

Will the solution be manual or automated? costly customization or the development of add-ons. 

A number of functions could be managed manually, 60 It is important to understand the level of integration 

especially if the functions are not directly related to the between products, however, before buying them. Integration 

systems, or are performed infrequently. Many of the varies from vendor to vendor and can mean anything from 

functions, however, require an interface to the systems, or simply having an icon on a desktop to fully integrated 

involve large volumes of data. ^ applications and data. In addition, integrated toolsets are 

Is integration with any existing systems required? 65 Ukely to be stronger in some functions than in others, and 

If integration with existing systems is necessary, hooks may preclude selection of the best possible tool for every 

may need to be built into both the existing and new systems. function. 
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Anticipated Volume of Data & Traasaction Throughput iofonning users when incidents have been resolved and 

Understanding the anticipated volumes will provide key ensuring resolution was complete, 

input to sizing the system. Predicted business volumes stated in addition. Incident Management is responsible for 

in the SLA should be used to help determine the appropriate ensuring that outstanding incidents are resolved in a timely 
sizes for machines, databases, telecommunications lines, 5 manner. As part of Incident Management, incidents are 

etc. Alternatively, expenence from previous engagements reviewed, analyzed, tracked, escalated as necessary, and 

can provide useful input. resolved 

Number of Users for the Tool Failure Control (1310) 

Users may not be limited to the number of support j^^^,^^^ ^^^^^^^ correction of faults within the 

personnel accessme a tool alone. Keep m mmd that users of ^ , l .1. ^ • / 1 . - j n 
K ^ , . _* 1 J 10 system whether they be mmor (e.g., workstation is down) or 

the tools may either be support personnel, vendors, users, /. . 

, i-r I- maior (i.e., a disaster) has occurred, 

senior managers, etc. c u x\ * 

o . 1 -11 1 * 1- J L r Fault Management (1312) 

Some tools will only support a limited number 01 users, „ „ ... 

. ^ . • u- u J When a negative event has been brought to the attention 

or may only support users within certam geographic bound- ^. ^ . . t^i^, 

\, . . V, ^ * J * J -c *L L or the system, actions are undertaken withm rauit Manage- 

anes. It is unportant to understand if there are any such , , • , . 1 * . . » • 
...... . . . . . I 15 me nt to detme, diagnose, and correct the taulL Although it 

limitations prior to purchasmg a tool. . 1 . ^ ' ■ i_ • . 

T jj *- u e 11 «• ♦ fu u J . may be possible to automate this process, human mtcrven- 

In addition, the number of users will affect the budgetary - . 1- , 

. c .t. u c . 1 1 1 hon may be required to pertorm at least some or these 

requirements for the purchase of a tool, particularly as they , 

^ ' ' manap'ennfirit tssKS 

relate to hardware and communications requirements. ^ ^ ^^^^m^ 

- , c o n • J Event/Data Generation (1314) 

Level 01 Support Reqmred / , - - • . .t . 

rr *L ' J c* • * u L J 1 • * 20 bvent/data generation mteracts with all the maoaged 

It third party so it ware is to be piirchased, suppuers must - . . 1 • 

, J *L • i * -1 u -i * components in the execution and development environments 

be assessed on their abibty to ensure the availability, . ^, ... • . • ^ 

1- t--i-. _r A r *!. * 1 n ^ order to obtain the required management iniormaUon. 

reliability, performance and user support tor these tools will ™ . . 1 - . . -.1. *l i_ • 1 

u n- - . . J 1- ..L r 1 1 r ■ * *u This component also interacts with the physical 

be suiBcient to deuver the appropriate levels 01 service to the . ^ - . , , . ~ 

r ^ 1* L * - 4 environment, managing hardware, and supportmg mfra- 

users 01 the system. It may even be necessary to visit r < . , . ■ 

f r ^ „ * ^ * • L »t- 25 Structure components 01 the operational architecture to 

reierence sites tor the vendors to de term me whether these , . • . % . . 

^ ^ u ' ™ » obtain management mtormation. It is important to consider 
requirements are being met. . - r 1 » - , » 
Presentation (1302) these mtertaccs when choosing event/data generation com- 
™ ^ -j.u ^f ponents. Agents and proxies are two common types of 
The presentation component provides the interface ^ ^ , ^i- , , . . 
. . ^ \ f *u * J event/data generation tools. Often these tools use broadcast- 
between the manager* s) of the system and management data . J* ■ ^t. J . ^ - i: A 1- 

* J L. *u * T^ / L • I * J r ^0 ing and trapping methods to capture mformation. Apphca- 

generated by the system. Data can be manipulated for . . ^ / , , 

. c r *.n * ^- 1 hon generated events from vendor packages and user apph- 

vanous torms of output. By mtegratmg the operational - j ^ - r . . . 

, ' iTi * J rL u c c . A cations also fit mto this component of the operational 

architecture it is possible to reduce the number of front-end . . ^ *^ 

arcfutecture 

interfaces required. Commonly, the presentation component . . 

uses a GUI front-end interface. This component is also \t Y J • - n^- 

, ... J I.- * • 1 * ^5 Vennes that the system is contmually tunctionmg m 

responsible for real-time and historical report generation. , -1, ,^, 

Event Processing (1304) accordance with whatever service levels are defined. 

Event processing manipulates the raw data obtained in the Event Management (1318) 

* 1 • * J ui c An event is an electronic message generated by any 

event/data generation layer mto a more workable form. This . • r, ^ ^ / ^ 

, rT A *• u * cu • 1 * component (e.g., appucation sottware, system sortware, 

layer performs functions such as event filtering, alert . / V - . ^ - 

, , ^. 4 11 ^- J 1 • 40 hardware, etc.) in the system. Event Management receives, 

generation, event correlation, event collection and logging. , 1 , ^ , I 

° J ^ , J. Li 1 . * t-c & logs, classifies and presents event messages on a console(s) 

and automated trouble ticket generation. Event processing . t . l j ci. tf u 

. J * c ..^^ . -.u *i- * based on pre-established niters or thresholds, 

routes the processed information on to either the presenta- * i- • ^^-^^^^ 

.... , A ■ • • Management Apphcations (1320) 

tion or management appucations layers. Again it is impor- . . . ^ ^ . . - , 

. J ■ * _r r *u 4 Management applications are those tools which are used 

tant to consider the mterface of the event processmg com- ^. r.v-^r^r.^ 

. r ^. , 45 to manage the system. Most of the MODE functions tie 

ponent with the other components of the operational ™ ... 

architecture duecUy into this component. 1 he management applications 

Hel Desk (1306) component ties in directly with the integration platform 

A •*u r- J II o • • .u .^-..1,1 J ! .u component as the management applications tools must CO m- 

As with End User Services in the centralized model, the ... , 1 . . • , 

„ , 1 • .u 1 - . f * » p 11 ^ ply with the standards set by the integration platform. For 

Help Desk is the smgle pomt of contact for all end users. *^ . . ^ • ,,,, ^ w- 

rw,.^ ... J* J * uM* r 11 -J * 50 example, if the integration platform is HP Open View, then 

lliis unit has end-to-end accountability tor all user incidents , ^ . . , , 

and problems regardless of whether or not it has the ".Tof et?^™''P^ must be HP Open View soft- 
. c .7 . * * .u ware (API, SNMPx) or hardware (card) compliant. Man- 
resources to fix them (i.e., U must contact the necessary ^ ,. . ,^ 
. 1-1 • ic - *• * *L agement applications receive data trom the event/data 
techmcal resources in either IS organizations to ensure the * . . . . 
. ... . , , . ^ A\ generation, event processing, and repositories components 
mcidents and problems get resolved). jj l - • 
Incident Mana emenl (1308) ^ ^ ^'^ presentation or repositones com- 
° . ^ A «u • . _r u *, .u ponents. Management applications tools include capacity 
Incident Management provides the mterface between the . , i- , 
users of the system and those operating and maintaining the P'*""^"^ f rf°nnance management tools, license 
system when an incident arises. Incident Management is 'oo's- remote management tools, systems 
restjonsible for' momtonng tools, schedulmg tools, help desk tools, etc. 

- 60 Some Enterprise Management tools even poll the event/data 

reoeivmg incidents from users generators for information but these options may impact 

informing users of known work-around where possible ^^^^^^^ performance. Web Server management is been 

ensurmg that support personnel are working on an mci- inu-oduced as part of the management operations frame- 

^^^^ work. As Corporate Internets and Extranets implement Web 
keeping users informed of incident resolution progress 55 based software products to sell and advertise business 

ensuring that incidents do not get lost as they are passed services, corresponding administrative, security, event noti- 

around support teams fication and performance requirements must be performed 
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similarly for the companies web based system. The critical improve the responsiveness and reputation of the entire 

path issues for Web based server software is typically organization. (Case based tools will require building up over 

security and performance based levels of service. time.) 

Help Desk (1322) Incident Management 

As with End User Services in the centralized model, the 5 Incident Management provides the interface between the 

Help Desk is the single point of contact for all end users. users of the system and those operating and maintaining the 

This unit has end-to-end accountability for all user incidents system when an incident arises. Incident Management is 

and problems regardless of whether or not it has the responsible for: 

resources to fix them (i.e., it must contact the necessary receiving incidents from users 

technical resources in either IS organizations to ensure the to ^^^^^ ^j^rs of known work-around where possible 

incidents and problems get resolved). • , . i .... 

Implemenution Cbnsidelations "^"""S '^'^ ^"PP"^' personnel arc woctang on an mc,- 

The following are functional requirements for Incident, 

Request and Problem Management. keeping users informed of incident resolution progress 

Ijogging Incidents/Requests 15 ensuring that incidents do not get lost as they are passed 

Call logger should be presented with a unique incident/ around support teams 

request identifier, and should be able to enter a free format informing users when incidents have been resolved and 

description as well as the key data items specified in the data ensuring resolution was complete, 

requirements section. Data and time stamps should be auto- Id addition, Incident Management is responsible for 

matically registered and Incident and Request management 20 ensuring that outstanding incidents are resolved in a timely 

staff should have access to display all open incidents and manner. As part of Incident Management, incidents are 

requests as well as the incident/request history for a specific reviewed, analyzed, tracked, escalated as necessary, and 

user location. resolved. 

Progress Incidents/Requests Implementation Considerations 

Facilities should be given to provide a free format update 25 Will users be given access to the Incident Management 

of actions and investigations, to assign the incident/request system? 

to a support group, or to escalate the incident. Date and time Users will benefit by gaining up to date information on the 

stamps should be attached to each action and the full progress of incidents, and could be given the facility to log 

incident/request history should be available to the person incidents directly, which would relieve some of the load of 

performing the update. 30 the Incident Management function. However, this adds 

Re-assign Incidents/Requests complexity to the solution, and increases communications 

Possible for incidents and requests to be assigned to requirements/costs, 

different support groups, if further investigation is required. Which support persotmel will be given access to the Incident 

Close Incidents/Requests Management system? 

Incidents and requests should be closed with a date and 35 Support personnel would be able to enter progress against 

time stamp to help trend analysis and service level reporting. incidents without contacting Incident Management. The 

Log Problems ability to scan incidents may also aid the Problem Manage- 

Problems can be logged both as a result of one or more ment function. However, this adds complexity to the 

incidents, or through proactive monitoring of the system, solution, and may increase communications requirements/ 

before any incidents have been logged. 40 costs. 

Support the functions either centrally or on a distributed How many incident support levels will be in place, and how 

basis expert will the Incident Management function be? 

If the Incident, Request and Problem management func- This will depend on the knowledge and experience at the 

tions are to be centralized, these functions need to be able to user locations. The level of technical expertise within the 

control and monitor incidents and problems, but other func- 45 Incident Management function will drive the systems 

tions should be able to gain access to input detailed technical requirements, 

information or progress updates. If Incident and Request Problem Management 

management is distributed, it is recommended that remote Problem Management utilizes the skills of experts and 

locations are given access to the central system, rather than support groups to fix and prevent recurring incidents by 

operating local systems. (Some problem areas are local sites 50 determining and fixing the underlying problems causing 

operating on different time zones and standardizing escala- those incidents. Within Problem Management, related inci- 

tion procedures from local sites.) dents are correlated to problems and ultimately to order or 

Facility for auto- logging incidents change requests. All problems are logged, tracked and 

Event/alert based automatic logging of incidents to pro- archived. Where possible, work-around are determined and 

vide proactive management of incidents and problems by 55 information regarding the work-around is distributed to the 

informing Incident management of issues before the user appropriate support personnel and user communities. 

logs a call. This facility is conceptually desirable, but is only Implementation Considerations 

likely to be available if the Incident management function- Will problems be automatically logged or only by manual 

ality is part of the monitoring tool. The costs of building association with an incident? 

hooks between tools and applications are hkely to prove 60 Automatic logging of problems will require interfaces to 

prohibitive. In medium or large environments, this facility is be built with the Event Management system, and perhaps the 

extremely desirable, and must be built into the requirements. execution architecture for application errors. 

Assess incidents automatically, based on previous experi- Request Management 

ence and rules Request Management is responsible for coordinating and 

Knowledge and case based incident management systems 65 controlling all activities necessary to fulfill a request from 

are becoming prevalent in the market place, and are built either a user, vendor, or developer. Request Management 

into Help Desk offerings. Use of these systems can help determines if and when requests will be fulfilled through 
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interaction with the particular function(s) impacted by the back costs based on pre-defined algorithms and bills users 

request. Following such interaction, accepted requests will for service rendered. 

be planned, executed, and tracked. Billing & Accounting also makes payments to service 

Implementation Considerations providers for services and equipment provided in acoor- 

Will users be given access to the Request Management 5 fiance with agreed upon SLAs. As part of this payment 

system? process Billing & Accounting reconciles bills from service 

Users will benefit by gaining up to date information on the providers against monitored costs and SLA/OLA violations, 

progress of incidents, and could be given the facility to log Systems Management Plannmg (1330) 

incidents directly, which would relieve some of the load of Capacity Modeling and Plannmg 

the Incident Management function. However, this adds lO ^^P^^^^^^ Modeling & Plannmg ensures that adequate 

1 * 1 J • • *• resources will be m place to meet the SLA requu^ments, 

complexity to the solution, and increases communications , • -^ j *- i * u 

\ ^ ' keeping in mind operational requirements which may 

tr -1 * n \ i\ x^A\ require additional capacity. Resources can include such 

hailure Control (1324) y^m^s as physical facilities, computers, memory/disk space. 

Involves the detection and correcuon of faults withm the communications lines and personnel. Through this 

system whether they be minor (e.g., workstation is down) or 15 component, changes to the existing environment will be 

major (i.e., a disaster) has occurred. determined, modeled and planned according to the neces- 

Fault Management sary requirements. 

When a negative event has been brought to the attention Production Control (1332) 

of the system, actions are undertaken within Fault Manage- Ensures that production activities are performed and 

ment to define, diagnose, and correct the fault. Although it 20 controlled as required and as intended, 

may be possible to automate this process, human interven- Production Scheduling 

tion may be required to perform at least some of these Production Scheduling determines the requirements for 

management tasks. the execution of scheduled jobs across a distributed envi- 

Disaster Recovery ronment, A production schedule is then planned to meet 

In the event of a significant system failure. Disaster 25 ^^^e requirements, taking into consideration other pro- 
Recovery processes will be invoked to re-route the system ^^^^ occurring throughout the distributed environment 
resources to a secondary, stable configuration until the (^ g- software and data distribution, remote backup/ 
primary resources can be restored. Within a distributed restoration of data.) It plans the production workload and 
environment, disaster recovery must account for differing ^^^'"^^^ P^^P^^ sequence, 
levels of disaster whether at a central or distributed site(s). 30 P^^"'^ ^P*'" detectmg a failure, provides on-Une 
Implementation Considerations T\ ^l^^^^^^^. forecasting. 
What is a disaster? Implementation ConsideraUons 

The way in which a disaster is defined will be dependent \ distributed enviromnent are processes across entire or 

upon which resources are critical to the business. For "^^^^^P^^ platforms and systems? 

example, a data center faUure may be critical for one cHent 35 Processes may be takmg place across the entire system on 

whereas a server failure for another is more critical. °?^**[Pl,^ platforms m either a parallel or a serial fashion. 

How quickly will disaster recovery be required for each ^^^f" dependencies may be required across platforms, and 

service? multiple time zones may be mvolved. In addition, many 

This wiU be defined in detail within the SLA, but high non-mainframe based products do not provide production 

level service recovery targets must be understood, so that 40 scheduhng capabilities with the platform. Therefore, one can 

high level recovery plans can, in turn, be produced. ^^^^ schedubng processes across a distributed environ- 

Recovery ^^xA. can be quite complex, requu-ing significant manage- 

Recovery manages all of the actions needed to restore ^^^^^ to ensure that processes occur appropriately, 

service delivery after a system failure. With critical business ^'^^y schedulers will be used to control the schedules? 

applications being rolled out on distributed technologies, the 45 Dependmg on how the function is to be controlled, and 

recovery of these systems must be easy, quick and efiScient °i^°y platforms are to be supported: 

to guarantee availability of core business systems as Luteal control of a single device with a single scheduler 

expressed in the agreed service levels and operational levels. (typically mainframe) 

Implementation Considerations Remote control of a single device with a single scheduler 

What are some of the limitations that are encountered? 50 Remote control of multiple but independent devices with 

Recovery capabilities span the range from those required a single scheduler 

to bring up a device after it has failed to those required in the Product Considerations 

event of a major disaster. With critical business applications What is the Intended use of the tool? 

being rolled out on distributed technologies, the recovery of The component plans for the production workload and 

these systems must be easy, quick and efficient. Loss of the 55 then submits the tasks to the system in the proper sequence, 

system for even a short period of time can result in signifi- stops processing upon detecting a failure, provides on-line 

cant financial losses to a clients business. task tracking and workload forecasting. In addition, require - 

Hardware Maintenance ments are determined for the execution of scheduled jobs 

Hardware Maintenance maintains all of the components across the environment, 

within a distributed system to protect the investment of the 60 Does and existing component satisfy this requirement? 

organization. Generally agreed upon in the SLAs, mainte- Production Scheduling contains specific requirements that 

nance contracts are carried out, monitored and recorded for addresses a distributed environments complexity of multiple 

each asset as appropriate. platforms and system placed in either a parallel or serial 

Administration (1326) fashion. 

Billing and Accounting 65 What other utilities are available with the tool? 

Billing & Accounting gathers the necessary accounting The tool should provide control dependencies to schedule 

information for calculating actual costs, determines charge- workloads such as: Task/job sequence enforcement. 



05/16/2002, EAST Version: 1.03.0002 



us 6,3 

115 

exlernal/internal event driven. Graphically displays work 
flow from the scheduling criteria and includes such infor- 
mation as task/job name, task description, average run time 
and resource requirements. AUow clients to define user 
schedules that can be based on predecessor events in the 
production environment. Reporting capabilities for 
forecasting, simulation and analyzing scheduled workload. 
Monitoring capability of past, present and future workloads 
as well as tracking of current workload termination notifi- 
cation of normal or aboormal completion. 
Does the development team have any prior experience with 
the tool? 

The development should be able to identify the compo- 
nent linkages as well as the functional requirements critical 
for successful operational integration of the tool into the 
observed environment. 
What level of the component is required? 

Due to the complexity of a distributed environment one 
must account for the processes taking place across the entire 
system on multiple platforms in either a paraUel or a serial 
fashion. Therefore, production scheduling capabilities 
across platforms is critical as weU as the ability to rerun/ 
restart from single point of failure or provide checkpoint 
restart-ability. 

Does the tool provide facilities to add color to MODE 
architecture model? 

Communication with Performance management compo- 
nent to forecast resource requirements, such as near line 
storage, DASD space, and etc. 
Interface with the Configuration management component 
facility to obtain configuration data in workload fore- 
casting. 

The scheduler will communicate with other schedulers on 
other systems to run a in a close relationship with the 
abiUty to support multiple heterogeneous platforms: 
MVS, Windows NT, UNIX, and AS/400. 
Communicates with Backup/Restore to identify schedul- 
ing constraints due to backup and restoration functions. 
Communicates with the recovery facility to dynamicaUy 
switch workload from one processor to another in the 
event of a system failure. 
Print Management 

Print Management monitors all of the printing done across 
a distributed environment and is responsible for managing 
the printers and printing at both central and remote locations. 
The purpose of a print architecture is to make formats 
applications independent, so that the only thing appHcations 
need to do is obtain the data. 
Print Architecture offers: 

It provides independence from printer devices and lan- 
guages 

It makes it easy to develop and maintain report 
Paper consumption may be reduced 
Reports arrive to the addressee more quickly 
It is possible to sign reports electronically 
Confidentiality is improved as people can only see infor- 
mation that can be accessed with their security level. 
Implementation Considerations 

What types of printers will be required (e.g., laser, impact, 
insets, etc)? 

The types of printers will be dictated by the business 
requirements. The types of printers, will in turn, determine 
what tools can be used to manage printing may or may not 
be required. 
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Where are the printers going to be located? 

The business will help determine where the printers need 
to be located based on where/when printing needs to take 
place. In some instances local printing may or may not be 
5 required. 

What spooling facilities will be available? 

If spooling is available, printing can be handled as a 
background task, freeing up system resources for use 
on-hne. 

Will review before print facilities be provided? 

If these facilities will be provided, all material will not 
need to be printed. If the material does need to be print; 
however, the location of the printing must be determined, 
and the system must be able to forward the printing on to the 
appropriate location. 
1^ Will printing of large documents be necessary? 

Large print jobs may utilize system resources consider- 
ably (e.g., WAN, LAN, printer), and may tie up the printing 
queue for other individuals. This type of printing should be 
performed in off-hours or delayed to avoid contention for the 
20 printer during business hours. 

What are some limitations that may be encountered? 

In a distributed environment the sizing and routing of 
print trafi&c is more complex. With new systems being 
instaUed, only educated guesses about how and when print- 
25 ing will take place can help determine print routing func- 
tionality. In most cases, some adjustments will be required 
to the print routing algorithms post-rollout to reflect the 
printing reality. 
Product Considerations 
3Q What is the intended use of the tool? 

Controls report production and distribution form the 
moment the report is created to the time the printed report is 
dropped in the end-use s mailbox (electronic, paper, 
microfiche, etc.) 
35 What other utilities are available with the tool? 

Provide queue management and abiUty to prioritize. 
Provides a full featured on-line viewing system. 
Provides for the archival of reports in a compressed 
format first on disk, for a user specified time and then 
40 to tape of optical. 

Process reports in due-out-sequenoe. 

Automatic report balancing and archives the balancing 

reports for easy auditor review. 
Provides a common output spoofing and printer device 

control capability across the network. 
Provide report reprint capability, avoid reruns in lost 

report situations. 
Provide centrafized management of report setup and 
delivery infiarmation 
How well does the tool integrate with other tools in the 
environment? 

Interfaces with the performance monitoring to identify 
bottlenecks in the distribution process 
55 Nofifies the service level management facility of any 
missed service commitments. 
Communicates with the documentation management 
facility to obtain the distribution information, media 
type and service level commitments. 
60 Communicates with the recovery management facifity to 
delete reports that will be recreated. 
Communicates report volumes to the resource consump- 
tion management facility. 
Does the tool provide support for specific areas? 
65 Support multiple printer types as well as report dehvery 
across them. This includes printer format translation (PCL, 
Postscript, etc.) and code translation. 
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Any other specific functional requirements? 

Output management issues require leverage of existing 
print capability, local and remote printing, and distribution 
management through a software package or an equivalent 
alternative. 

File Transfer & Control 

File Transfer and Control initiates and monitors files 
being transferred throughout the system as part of the 
business processing (e.g., nightly batch runs). File transfers 
may occur between any two or more devises within the 
system. 

System Startup & Shutdown 

System Startup and Shutdown performs the activities 
required for the startup or shutdown of the entire system 
(e.g., hardware, applications), or portions of the system 
depending upon the identified requirements. Within a dis- 
tributed environment, the system includes both centralized 
and remote resources. 
Implementation Considerations 

Will devices need to be shutdown/started remotely as well as 
be automatic or manual (e.g., using scripts, embedded in 
schedule)? 

If expertise will not be available locally, it is imperative 
that remote control of the startup/shutdown processes be 
available. The presence of skills, the availability of tools, 
and the uniqueness of the application/environment will 
dictate whether or not startup/shutdown is automatic or 
manual. 

How will clean shutdowns of all processes be ensured? 

If a system failure takes place, it is important that all 
processes be shut down well, to ensure that the processes can 
be re -started and that the integrity of the information will be 
maintained. 

In what order will hardware and software components be 
started/shutdown? 

Based upon the technical requirements of the system (e.g., 
databases should be started before applications) as well as 
defined service levels (e.g., one particular application is 
critical and must be started first), the order of startup/ 
shutdown will be determined. 

Are periodic re-boots required (e.g., to clean up memory)? 

If this is necessary, automatic/manual startup/shutdown of 
the system should be scheduled (e.g., U^^X systems require 
this). 

Analysis of the system and other resources need to be 
addressed? 

The state of an application, the system or a specific 
resource must be known at all times. Common activities 
performed as part of Startup/Shutdown include: 

logging on 

virus checking 

version checking 

process initiation/completion 

housekeeping 

logging off. 

Some hmitations that may need to be taken into account? 

System startup and shutdown is no longer confined to a 
centralized site. The system is distributed, in effect creating 
islands of technology which may be started or shutdown 
with the flip of a power switch on a workstation. Processes 
which rely on the system being up and running (e.g., 
software and data distribution) may fail if a user has 
switched his/her machine off before leaving for the evening. 
Such failures will impact the following days processing 
capabilities and must be accounted for either by the system 
or through training. In addition, controlled machine startup 
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may be required to initiate tasks or to perform activities such 
as configuration checking or virus detection/correction. 
Mass Storage Management 

Mass Storage Management involves those activities 
5 related to the handling of various types of centralized and 
distributed storage media including the monitoring and 
controlling of storage resources and their usage. 

The objectives of Mass Storage management are to: 
implement the top level of storage management, control the 
usage level of each storage device in the distributed 
environment, control all storage related naming standards 
and placement details in the installation. 

Mass Storage Management is more complex in a distrib- 
uted environment than in a centralized environment since 
many more storage options become available, as storage 
may take place centrally or on a distributed basis and the 
number and characteristics of storage devices have 
increased. 

Implementation Considerations 

What DBMS will be used and what utilities does it have? 
20 The DBMS will often provide much of the necessary 
storage management functionality; this decision impacts 
further requirements. 

Will databases be distributed or centralized? 

Storage management for centralized databases will 
25 clearly be simpler then for distributed databases were a 
global view becomes more diflScult to obtain, and where data 
consistency becomes more of an issue. 
What media types will be used? 

It is essential that the types of device to be used are 
3Q understood before detailed decisiotis are taken. 
Distributed Environmental Constraints? 

The allocation and sharing of storage media is more 
difficult to plan since users are distributed. Mass Storage 
Management is more complex in a distributed environment 
35 as many more storage options become available; storage 
may take place on disks, tapes, etc. Either centrally or 
de-centrally. 
Product Considerations 
What is the Intended use of the tool? 
4Q Control and manage the data storage environment includ- 
ing any/all media, disk, optical and tape. 
Technology's ability to support the Operating Systems 
within the distributed environment? 

The tool must run in the platform selected in order to 
45 control usage of disk space, main memory, cache, etc. In 
addition, determining the space available helps control the 
device usage, storage capacity 
What other utilities are available with the tool? 

Continuous analysis of the data storage environment to 
50 insure optimum storage utilization and location. 
Eliminate fragmentation by reordering files 
All storage devices managed independently of their type 
and location in order to avoid storage problems, 
bottlenecks, etc. 
55 Should the tool provide specific component functionality? 
The tool should take into account the complexity of the 
distributed environment as well as the flexibifity of the 
scenario that storage may take place centrally or on a 
distributed basis and the number and characteristics of 
60 storage devices have increased. 

Does the tool provide support for the databases selected for 
the distributed environment? 

Additional facilities may be required, even although data- 
bases typically have built-in utilities or tools to perform 
65 these function and do not generally require a separate tool. 
Does the tool provide facilities to add color and support 
linkages to MODE architecture model? 
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Communicates with the Performance management facil- 
ity to identify any performance problems and relocate 
data based on the performance analysis. 

Communicates with operation system error logging and/ 
or the Operations Automation to identify any potential 
media or hardware failures and relocate data, automati- 
cally files a problem log for corrective action. 

Interface with the Capacity/Resource manager to create a 
definable resource forecast. 
Backup/Restore Management 

Backup and Restore Management considers all of the 
back-up and restorations that need to take place across the 
distributed system for master copies of data. Depending on 
the need, these processes may occur centrally or remotely. 
Implementation Considerations 
What data/files will be backed up? 

Files that are either unique, store site specific data or are 
highly volatile should be backed up. This will help ensure 
that important, business critical data will not be lost in the 
event of a system failure or disaster. All files do not 
necessarily need to be backed up as each file backup utilizes 
storage space and ma impede the performance of the system. 
What will be the frequency of the backup, the number of 
copies made, and the number of generations maintained? 

The critically and volatility of the information will deter- 
mine the frequency of the backups and whether or not 
multiple copies of the data are maintained centrally /locally. 
In addition the stability of the system needs to be considered 
as weU as any performance impacts of backing up the data 
as required. 

The number of generations maintained will be dependent 
on the disaster recovery policies in place as well as any 
goverameot/regulatory controls in existence- 
How will the integrity of a backup or restore be ensured? 

Because databases can be located throughout the distrib- 
uted environment, care must be taken to ensure that data 
integrity is maintained. This may mean storing the master 
copy of data centrally, or synchronizing the commits of 
updates of the information appropriately. 
Will the data be backed up centrally, locally, or at an 
alternate site? 

Centrally located devices will require the use of both 
LAN and WAN bandwidth to backup the data, and restora- 
tion of the data will be slower. This may be hard to achieve 
if there are numerous devices in the system. Central 
location, however, will ensure that backed up data will be 
stored in one place, potentially making recovery from a 
system failure or disaster recovery easier as well as centrally 
less expensive to maintain. In addition, central control over 
the backup/restore process will require expertise at a single 
location whereas local control will necessitate expertise in 
multiple locations. Alternate site control may provide the 
best mix of central/local placement of skills. 

In contrast, local devices do not utilize the WAN 
bandwidth, and typically provide faster data restoration. 
Local devices, if available, may be more expensive and may 
require local expertise. 

Alternate site backup combines both of the strategies in 
that WAN bandwidth to the central site is not over-utilized, 
and restoration of the data can happen fairly quickly as well 
as securing information as information is stored in multiple 
locations. 

Will copies be held at multiple locations? 

Backup copies may need to be stored at multiple locations 
for security purposes (i.e. in the event of a system failure, or ' 
disaster, some backup copies may have been destroyed.) 
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Product Considerations 
What is the intended use of the tool? 

Provide services and facilities to enable the client to effect 
timely and accurate recovery in the event of an interruption 
5 to processing capability. 

What other utilities are available with the tool? 

The backup product should have fundamental manage- 
ment capabilities. Automatic restore, unattended opera- 
tion and command line processing of the product 
10 should be available. Basic tape functions such as 
cataloging, internal labeling, initialization, 
certification, scratch protection and write protection are 
musts. 

Performs automatic backup of data files on site standards. 
15 Designed along the lines requester-server model; more 
specifically the tool mns on the server machine and acts 
as a shared resource for data access, integrity, security 
recovery, etc. 

Full auditing capability should be present for backups as 
well as error detection and notification that a backup 
has failed should be available. 
Provide full and incremental backups, partial restore, and 

compression/decompression. 
Capable of managed and systematic restore process. 
How well does the tool integrate with other tools in the 
environment? 

Backups are typically embedded into production sched- 
uling with restores on an ad hoc basis. Backup/Restore needs 
to ensure that a file can be only backed up/restored by users 
with the right access level. Furthermore, file transfer utilities 
need to be used when the information to archived is sent 
through the network as well as security for file control access 
and global authorization should be available and done in 
concert with the security management facility. 
Should the tool provide specific component functionality? 

Database backup/restore is inherently more complex than 
backup of standard files. It is important to ensure that all 
relationships are resurrected after restoring database files. 
(Integrated with the functionality of the DBMS) 
Does the tool provide support to specific areas? 

The product should support multiple heterogeneous plat- 
forms: Windows NT, AS/400, MVS and UNIX. 
Software features of the product should support items 
45 such as direct file access, direct volume access and 
extended attributes. The ability to backup the operating 
system files. Support should also handle open file 
backups either waiting and retrying or taking a fuzzy 
backup. 

50 Dual logging support in the DBMS is required, both for 
online and archived logs. 
Pint in time recovery of database and database compo- 
nents must be supported. 
Ability to support various types of storage devices 
55 (magnetic disc, cartridge, tape, optical disc.) 

Does the tool provide support for a specific environment? 

The ability to support unattended operations reduces the 
need for operations expertise in both central and remote 
locations 

60 Does the tool add color to MODE architecture model 
through performance measures? 

Performance of the backup product is essential. The tool 
should backup all production data in the processing window 
provided and the restore capability should match availability 
and disaster recovery requirements. Performance can be 
enhanced through the ability to throtde the backup process 
to reduce network traffic. 
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Archiviog 

Archiving saves and stores information across the distrib- 
uted environment, either centrally or in distributed locations. 
Archiving moves dataseis, files, etc. from one device to 
another, usually lower speed, device based on a number of 5 
parameters. Archiving can be used to move information to or 
from distributed and centralized sites. 
Implementation Considerations 
Which files and databases will be archived? 

Some files and databases need to be stored on fast devices lo 
so users can access them quickly. In addition, certain files 
may need to be maintained for either historic or government/ 
regulatory reasons. 

What media will be used for archiving? 

The cost of the media, space available and its performance 15 
capabilities should determine which archiving medium is 
used as well as the existence of central or local expertise. 
How long should archived data be maintained? 

It is important to define the maximum time that data needs 
to be stored before being deleted, including the number of 20 
generations that need to be maintained. This is because the 
amount of archival space should be determined up front. The 
maximum time will likely be determined by either 
government/regulatory controls or disaster recovery require- 
ments. 25 
How will the integrity of retrieved data or files be ensured? 

Because databases can be located throughout the distrib- 
uted environment, care must be taken to ensure that data 
integrity is maintained. This may mean storing the master 
copy of data centrally, or synchronizing the commits or 30 
updated of the information appropriately. 
Will archiving devices reside centrally or locally? 

Central control over the archiving process will require 
expertise at a single location whereas local control will 
necessitate expertise in multiple locations. 35 

Centrally located devices will require the use of both 
LAN and WAN bandwidth to archive the data, and retrieval 
of the data will be slower This may be difficult to achieve 
if there are numerous devices in the system. Central 
location, however, will ensure that archived data will be 40 
stored in one place, potentially making recovery from a 
system failure or disaster recovery easier. In addition, central 
devices may be less expensive to maintain. 

In contrast, local devices do not utilize the WAN 
bandwidth, and typically provide faster data retrieval. Local 45 
devices, if available, may be more expensive, and may 
require local expertise. 
Implementing (1334) 

Executes change within the distributed environment with 
tested components and techniques according to the appro- 50 
priate plan(s). Implementing includes such things as: initial 
installation, software & data distribution, license 
management, etc. 
System Component Configuration 

System Component Configuration provides a mechanism 55 
to configure equipment (i.e., hardware and software) which 
has configuration parameters to set and to manage the 
inter-relationships between configured components within 
the system. Configuration information for particular equip- 
ment must be coordinated across the system to ensure that all 60 
equipment can function together properly. 
Implementation Considerations 
Where does the function get input from? 

Configuration settings can be retrieved from different 
sources. The release and the rollout schedule will contain a 65 
detailed description of equipment and its configuration and 
can therefore be used as input. Alternatively, the asset 
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inventory system can be updated in advance and then used 
as an active database to drive the configuring process. 
Product Considerations 
What is the Intended use of the tool? 

Definition and implementation of consistent configura- 
tions for all configurable components within the system. 
What other utilities are available with the tool? 

Hardware and Software should be configured accurately 
and with minimal business disruption during initial 
installation. 

Ability to re -configure hardware and software both locally 
and remotely. 

How weU does the tool integrate with other tools in the 
environment? 

The asset data has to be updated accordingly and must 
reflect the actual state of hardware and software and all their 
relationships. Configuration data may be distributed to the 
device by Software & Data Distribution; therefore. System 
Component Configuration needs to get access to Software & 
Data Distribution processes. 
Software & Data Distribution 

Software and Data Distribution sends out the correct 
version of the release package to the distribution locations 
and updates the locations with the contents of the release 
package (e.g., software, data, configuration information, 
procedures and training/support materials.) 

The software and data distribution mechanism itself 
updates either the software, data, or configuration informa- 
tion on a machine(s), reports the relative success/failure of 
the distribution and updates the asset information for the 
sites/machine(s) affected by the distribution. 
Implementation Considerations 
What are some limitations that may be encountered? 

Training Planning also impacts how well service will be 
delivered within the distributed environment. The skill sets 
required by support personnel will change with the intro- 
duction of distributed technologies. Support personnel will 
be required to have greater breadth of knowledge. No longer 
can an individual simply understand the network or the 
applications- The intertwined nature of a distributed envi- 
ronment will force individuals to understand, at least at a 
high-level, how the system fits together. In addition, support 
personnel will need to have some specialized skills. As no 
one individual can fully understand the detail behind the 
entire system, teams of specialized support personnel will be 
required to work together to a greater extent in these 
envirormients. This group interaction may require new skill 
sets not frequently found in traditional support organiza- 
tions. 

What are some focus areas to determine an appropriate 
training plan? 

The existing skills must be assessed and a forward- 
thinking training direction must be defined. The training 
plan will likely emphasize newer technologies and different 
methods of training with the underlying goal of providing 
the appropriate level of service as required by the SLAs. 
Product Considerations 
What is the intended use of the tool? 

Support the abiUty to distribute software components to 
interdependent, multiple heterogeneous platforms from a 
single source. The features should be automated and only 
require minimal operator involvement. 
What other utilities are available with the tool? 

Centralized control and administration of distribution 
function. 

Backout, configuration restoration capability, 
Schedulable, unattended distribution and installation of 
software. 
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Ability to generate distribution candidate lists frono asset/ 
inventory maoagement database. 

Logging of status/failures to centralized system monitor- 
ing facility. 

Ability to distribute release packages constructed in mod- 
ule control/versioaing facility. 

Pre-defined installation and de -installation scripts. 

Ability to perform complete back-out of all related seg- 
ments quickly and automatically, without impacting 
other, successfully installed updates. 

Features should include: data compression and 
decompression, check-pointing, and retry. 

Users should be allowed to postpone distribution to their 
workstation. 
What level of the component is required? 

The function must be able to access a release library, to 
identify release packages, release component groups 
and release components, and to associate the correct 
version number with these components. 

Ability to select destination nodes by certain criteria, such 
as location, hardware type, standard configuration at 
these nodes and to address these nodes in the network. 

The function must send to and install software and data at 
remote locations reliably and within an agreed time 
scale causing minimum disruption. 

The function must be able to back out remotely, either as 
part of the distribution or as a separate process. The 
mechanism must be able to regress to the previous 
operable state prior to disruption. 

Ability to synchronize data and lime between systems. 
How well does the tool integrate with other tools in the 
environment? 

Software & Data Distribution needs to access and update 
asset data in the asset inventory system to reflect imple- 
mented changes (automatically). In addition the function 
may be based on the same file transfer protocol as File 
Transfer & Control; unless the tools uses their own propri- 
etary file transfer method based on a standard communica- 
tion protocol. 

Does the tool provide support for specific environments? 

Specialized functionality to support operation across the 
wide-area network environment including: parallel distribu- 
tion and data compression. In addition, support of platform 
specific functions and capabilities due to awareness of 
platform specific information resident in the asset/inventory 
database. 

User Administration 

User Administration handles the day-to-day tasks 
involved in administering users on the system. These tasks 
include such things as: adding new users, changing user Ids, 
re-eslab fishing user passwords, maintaining groups of users, 
etc. 

Security Management 

Security Management controls both physical and logical 
security for the distributed system. Due to the nature of a 
distributed environment, security may need to be managed 
either centrally, remotely or through a combination of the 
two methods. 

Seciuity Management also handles the logging of proper 
and illegal access, provides a way to audit security 
information, rectify security breaches and address unautho- 
rized use of the system. 
Implementation Considerations 
Some fimitations that may be encountered? 

Security must exist in various levels throughout the 
system in order to prevent unauthorized access. Security 
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components must be packaged into a security architecture 
which can be effectively managed by an organization 
through their security management strategies. 
The number of security components required to secure a 
5 distributed environment will increase due to the computing 
power available through the use of these new technologies 
and the heterogeneity of the environment. Although things 
such as dial-up access, LAN access, multiple host access, 
etc. introduce new user capabilities, they simultaneously 
10 introduce security risks into the system. 

What are the benefits of single logon capabilities? 

Due to the number of components, users may be required 
to have multiple lD(s) and passwords unless the system is 
designed to allow a user to access all of the required 
15 resources through a single logon. As most products on the 
market typically allow access to only a subset of resources, 
single logons with multiple ID and password coordination 
may be difficult to achieve. Issues such as periodic required 
password changes can be difficult to overcome while main- 
20 taining adequate security. 
Product Considerations 
What is the Intended use of the tool? 

Protects all computer resources, facilities and data from 
accidental or intentional destruction, modification, disclo- 
25 sure and/or misuse. 

What other utilities are available with the tool? 

One User-ID for access to all software (central point for 

all security checking). 
Maintains a security log and user profile of what was 
30 accessed when, from a computer resource, facility and 
data view point. 
Security Administration ability to monitor the activity of 

a user of resource. 
Allows users capability, when authorized, to maintain 
^5 their own security profiles by individual or group. 

Access authority for database objects (data-sets) as they 

appear outside the DBMS must be controlled. 
Database authorities must be manageable at a group/role 
level. 

40 

Single user setup and sign -on capability across all plat- 
forms and applications. 
Virus protection on all platforms. 

Support for external security devices and dial access 
45 equipment, etc. 

Encrypted flow of security information across the net- 
work. 

Comprehensive access logging and auditing capabifity. 
Enhanced security capability beyond normally suppUed 
50 UNIX levels. This includes being able to support 
scoped UNIX administrative users (root subsets, lim- 
ited root functionality). 
Network Management 

Network & Systems Management Planning is responsible 
55 for the planning activities involved in running the day-to- 
day operations and maintenance of the production systems 
(e.g., capacity planning, performance planning, etc.). 
Controlling (1336) 

Monitors change to make sure that change is delivered 
60 on-time according to established plans, making adjustments 
to the plan when unforeseen issues or events arise (e.g., 
rollout management, change control, asset management etc.) 
Change Control 

Change Control is responsible for coordinating and con- 
65 u-olling all change administration activities within the dis- 
tributed environment (i.e., document, impact, authorize, 
schedule, implementation control.) 
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Implemenlatioa Considerations Centralized repository for software releases, including 

What types of changes will be controlled by Change Control current and back-level generations, 

and what is the anticipated volume of changes? Managetnent 

The types of changes Change Control should cope with ^ * * ... - . 

need to be defined. Changes can range from a minor 5 Asset Management ensures that aU assets are registered 

document change to the introduction of a complete new within the inventory system and that detaUed information for 

service. However, moving a workstation from one desk to registered assets is updated and validated throughout the 

another may not require a change request. assets lifetime. This information will be required for such 

Design of the function heavily depends on its size. It may activities as managing service levels, managing change, 

be a relatively small environment with little expected assisting in incident and problem resolution and providing 

change, or it could be a huge distributed system with many necessary financial information to the organization, 

locations, many users and many different platforms. Implementation Considerations 

It is easy to underestimate the volume and complexity of What data will be stored? 

changes in a distributed environment. Changes to different ™ * 

platforms can easily become very complS. Experiences ^here axe four options to consider, when designing the 

from previous engagements should be used to help predict i5 scope of the Asset Management function. Usage of the Asset 

figures. In a typical distributed environment, several hun- inventory only as a production system database (core 

dred changes per month can be expected. database), mcludmg hardware devices, software versions 

To what extent should Change Control be integrated with the lo^^ied in the production environment, their licenses and 

asset inventory system, maintained by Asset Management? network configuration data. Thus the asset inventory system 

Impact analysis can use Asset Management to get a 20 only stores the core systems components in the production 

detailed list of assets which are dependent on the subject to environment. 

be changed. It may be a mandatory requirement to provide Iq addition to the production system data as describes 

this list before a change request can be accepted. above, it contains any existing release and release compo- 

To what extent should Change Control be integrated with nents such as software modules, documents and procedures. 

Incident and Problem Management? 25 It also contains service level agreements and actual figures 

Change requests might be closely tied to mcidents and user groups and devices, incidents, problems and change 

problems, thus when a change is unplementei the corre- ^^^^ ^ ^ ^^j^^ additional data such as perfor- 

sponthngmadente and problems^ mance data or log of all backups taken. 

Which media will be used tor change request submission.' m j i_ 1 

Pure electronic forms will be easy to forward over dif- ^ ^^P^ up-to-date? 

ferent locations, but it is more difficuU to include a signature This can be achieved by regular and ad hoc audits, using 

feature for authorization, and it is not easy to attach docu- manual and automated procedures. An alternative approach 

ments to provide additional information. Therefore, further would be to use asset data to drive Software & Data 

paper forms are typically used for raising change requests Distribution. The Software & Data Distribution processes 

but the change administrator then stores the most important would get data from the asset inventory system as input If 

information in a change request database. The decision will ^5 processes configured the devices according to the asset 

depend primarily on the size of the system. inventory it would be up-to-date by definition. 

There are some limitations that may be encountered within y^^^^ y^^^ ^^^^^ ^ ^^^^^^ , 

a distributed envu*onment- Asset Manasement? 

There will be multiple change drivers including the users, , , . , • - ^ 

developers/architects and vendors. The change these groups 40 °^^y appropnate to control assets within the first 

will wish to introduce must be coordinated on a wide-scale cycle(i.e., from development on) or it my 

basis as the impact of change within these environments is P^^^^ ^^^^ appropriate to implement Asset Management 

great. Change Control allows the impact of the change to be only from the point of delivery, 

assessed along with its merits, timescales, etc. It also pro- Product Considerations 

vides a way of evaluating and rationalizing multiple change ^5 what is the intended use of the tool? 

requests against one another to determine what changes [^^i^t^^^ 3 ^^^^^^ repository for aU software licenses and 

should actually take place. assets 

Product Considerations ^n, . .u . i v- 1 ui %k *u * 10 

«7u f*u*!o What other utilities are available with the tool? 
What IS the intended use of the tool? 

Integrated central repository of source, change and con- 50 Software asset tracking by location/server, automatic 

figuration data used to pro-actively manage all events detection of correct level of software. 

impacting user service. Manage the process of change Authorize license use. 

activity, while maintaining the integrity of both application Perform periodic searches for unlicensed software. 

development and the production environment. Support r t 1 • 

change control from the initiation of the change, through ,5 ^^^^^^^ mventory system 

production configuration across multiple platforms. ^"^'^V ^^""^ ^P ^'^chi^e ^^et inventory system 

What other utilities are available with the tool? What are some of the inventory maintenance issues that 

Change requests need to be registered in the system, with °eed to be addressed? 

a unique number assigned as well as related incidents Ability to maintain a data model representing the basis for 

and problems. 50 inventory system that reflects the types of assets to 

The system must support update of change requests. be managed and their relationships. The model should be 

Updates may include changing priorities, results of the flexible to cope with fiiture strucmral changes. A record 

assessment, and adding a summary of the implemen- needs to be added to the inventory system when an asset is 

tation. purchased or created, or when changes to the environment 

Once a change has been implemented the change admin- 65 performed. 

istrator must complete the log by closing the change How well does the tool integrate with other tools in the 

request. environment? 
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Asset data needed to support various other management 
functions such as: 

Hardware Maintenance 

Release Testing 

Procurement 

Initial Installation 

System Component Configuration 

Software & Data Distribution. 
Does the tool provide support for a specific environment? 

Current asset data from the distributed environment needs 
to be retrieved frequently through regular and ad hoc audits. 
Rollout Management 

Rollout Management is concerned with delivering new 
sites or services to existing sites on-time based on the rollout 
schedule. Rollout Management monitors the rollout progress 
of all functions against the rollout schedule to ensure that the 
schedule is maintained. Review of the rollout schedule takes 
place regularly to determine how well rollout is progressing 
and to make any adjustments to the rollout schedule based 
upon any problems or issues which arise. 
Implementation Considerations 

What are some principles that should be applied in deter- 
mining rollout planning? 

At the beginning of a rollout, the number of incidents can 
be dramatic. This happens due to initial problems with 
hardware and system software as well as the un familiarity of 
the users. In addition to an increased support load, support 
teams will need more time to process an incident and to 
solve an underling problem since they will need to become 
familiar with the new service. Once support teams have 
become familiar with the system and know how to resolve 
the most common problems, rollout can be accelerated. 

Since many problems will occur initially during rollout, it 
is important to have quick access to support teams and 
development teams. If sites are close, support personnel can 
get to the sites quickly. Once the system is more stable, 
remote installation can occiw. 

Instead of planning a tight schedule that keeps teams busy 
all the time, some windows should be left in the schedule to 
allow catching up time in case of delays. Otherwise, small 
deviations to the schedule cannot be handled and larger 
delays to the entire schedule will result. 

When rollout continues over a period of time, hardware 
and system software updates will affect the initial imple- 
mentation of the system. The service to be implemented 
itself may also be updated during rollout. Therefore it is 
important to review hardware and software maintenance and 
release plans and to reflect these plans in the rollout sched- 
ule. 

Will the system be rolled out in one big bang or through a 
phased rollout over a longer period of time? 

Rollout of a new service can either be performed at one 
specific point in time for all locations or phased over a 
certain period of time. Phased rollout is the preferred 
approach because it limits the risk of serious business 
disruptions. In some cases, however, it may be necessary to 
complete rollout simultaneously for business reasons. 
What are some of the hmitations encountered in a distrib- 
uted environment? 

Rollout Plannmg handles the greatest period of change in 
distributed systems management — system rollout and instal- 
lation. During rollout every site and every user may be 
impacted by the changes taking place. Since delivery of the 
system will affect how well it is received by the users and is 
oftentimes defined by an SLA(s), delivery of the system 
must take place smoothly with minimal interruption to the 
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users. This can be challenging when both old and new 
architecture domains must exist coccurrently until the roll- 
out has been completed. 

Interdependencies within the schedule must be identified 
5 prior to rollout to highlight the importance of the schedule 
and the effort required from each group involved. 
Release Control 

Release Control is concerned with delivering a release 
on-time based upon the release schedule. Release Control 
monitors the release progress of all activities against the 
schedule to ensure that the schedule is maintained. Review 
of the release schedule takes place regularly to determine 
how well the release is progressing and to make any adjust- 
ments to the release schedule based upon any issues or 
problems which arise. 
Implementation Considerations 
What will be the versioning strategy? 

It is necessary to determine bow a release will be named 
and versioned. The following points should be considered 
when defining a versioning strategy. The versioning strategy 
20 should be kept simple and meaningful. Versions should be 
applied not only for complete releases, but for all logical 
groups of release components as defined in the release 
definition data model. Asset Management needs to reflect 
the release component data model in order to be able to store 
25 the asset information. In addition, the versioning strategy 
will affect Software & Data Distribution to ensure that the 
appropriate version of software/data is resident on the unit 
prior to implementing the new release, and co-requisite 
checking ensures that implementations of software/data will 
leave a machine in a valid state. 
How frequently should new releases be packaged? 

A minimum time interval between two regular releases 
needs to be defined. Most planned releases typically occur 
within three to six months of one another. 
Will delta releases be allowed? 

The need for delta releases as part of the overall pohcy 
must be determined. Delta releases are high risk, as they 
require a much better understanding of what is already 
implemented. 

Delta releases have the advantage of requiring less storage 

40 space on the target machine but it may be more diflScull to 
ensure that the base components are compatible. This can 
become a particular problem when many components have 
changed and several delta releases have accumulated 
Will simultaneous changes across platforms be required? 

45 Implementing releases in a distributed environment 
requires complex synchronization across machines and plat- 
forms. An appropriate strategy needs to be determined. 
What are some limitations that may be encountered at 
disUibuted sites? 

50 Release Planning coordinates the release of updates (e.g., 
software, data, procedures, etc.) to the distributed sites. An 
application, for instance, can no longer be delivered upon 
successful completion of its system test. This is due to the 
fact that any change in the distributed environment will 

55 impact other components in the distributed environment. 
Releases must therefore be planned carefully to ensure that 
a change will not negatively impact the distributed system. 
Product Considerations 
What is the intended use of the tool? 

50 Monitoring and delivery of releases as well as review of 
release schedule versus planned schedule. 
What other utilities are available with the tool? 

Provide management of source code, objects, executables, 
graphics, and documentation. 

65 Track and manage multiple versions of an application, 
such as development, staging, certification, production, 
and prior versions of production. 
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Provide automatic file versioDing, configuration 

versioning, release control, change tracking, etc. 
Populate multiple platforms with the correct code at the 

same time or on schedule, and provide update status. 
Confirmation of release schediding and determine if the 

release is on schedule and report on progress of release. 
If schedules have to be changed, changes need to be 

authorized by all involved functions and components. 
How well does the tool integrate with other tools in the 
environment 

Release Planning and Release Control naturally use the 
same tool, typically a spreadsheet, for creating and main- 
taining the release schedule. 
Migration Control 

Migration Control is a function underneath Release Con- 
trol. Updates to the distributed system must be tested prior 
to being released into the distributed environment. To con- 
trol the updates as the move from the development into the 
production environment, Migration Control ensures that the 
proper updates are received from development, versioned 
according to the version strategy of Release Planning, 
moved into the test environment, moved form the lest 
environment into the production environment after the pre 
release tests have been successfully completed. 
Implementation Considerations 
What units are subject to migration? 

The groups of components, which are allowed to be 
migrated, must be determined, for example: single software 
modules or documents can be migrated on their own and 
only complete releases (including delta releases) with all 
their components may be migrated. 
Where will the release library be located? 

The library can either be held centrally or can be distrib- 
uted over various sites. A centralized approach is preferable 
in order to avoid inconsistencies. 

Which platforms and media are used for the release library? 

The release library may reside of several platforms. UNIX 
software may be stored on UNIX servers, host software on 
hosts and third party workstation software may be on floppy 
disks. 

License Management 

License Management ensures that software licenses are 
being maintained throughout the distributed system and that 
hcense agreements are not being violated. 
Implementation Considerations 
What data will be stored? 

There are four options to consider, when designing the 
scope of the Asset Management function. Usage of the Asset 
inventory only as a production system database (core 
database), including hardware devices, software versions 
loaded in the production environment, their licenses and 
network configuration data. Thus the asset inventory system 
only stores the core systems components in the production 
environment. 

In addition to the production system data as describes 
above, it contains any existing release and release compo- 
nents such as software modules, documents and procedures. 
It also contains service level agreements and actual figures 
for user groups and devices, incidents, problems and change 
requests. It may also contain additional data such as perfor- 
mance data or log of all backups taken. 
How will data be kept up-to-date? 

This can be achieved by regular and ad hoc audits, using 
manual and automated procedures. An alternative approach 
would be to use asset data to drive Software & Data 
Distribution. The Software & Data Distribution processes 
would get data from the asset inventory system as input If 
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these processes configured the devices according to the asset 

inventory it would be up-to-date by definition. 

What phases of an assets life cycle should be covered by 

Asset Management? 
5 It may be appropriate to control assets within the first 

stage of the life cycle (i.e., from development on) or it my 

prove more appropriate to implement Asset Management 

only from the point of delivery. 

Product Considerations 
10 What is the intended use of the tool? 

Maintain a central repository for all software licenses and 

assets. 

What other utilities are available with the tool? 
Software asset tracking by location/server, automatic 
15 detection of correct level of software. 
Authorize license use. 

Perform periodic searches for unlicensed software. 

Central inventory system 
20 Ability to back up and archive the asset inventory system 
What are some of the inventory maintenance issues that 
need to be addressed? 

Ability to maintain a data model representing the basis for 
an asset inventory system that reflects the types of assets to 
25 be managed and their relationships. The model should be 
flexible to cope with future structural changes. A record 
needs to be added to the inventory system when an asset is 
purchased or created, or when changes to the environment 
are performed. 

30 How well does the tool integrate with other tools in the 
environment? 

Asset data needed to support various other management 
functions such as: 

Hardware Maintenance 

Release Testing 

Procurement 

Initial InstaUation 

System Component Configuration 
40 Software & Data Distribution. 

Does the tool provide support for a specific environment? 

Current asset data fi-om the distributed environment needs 
to be retrieved frequently through regular and ad hoc audits. 
Database Management (1358) 
45 Database Management is the management and adminis- 
tration of database technologies, including monitoring, 
physical file placement, performance, and sizing. 
Database Recovery 

Database Recovery is the process of providing recovery 
50 of database entities foUowing a logical or physical database 
failure. TTiis includes database software failure and local 
disk failure. 

Database Disaster Recovery 

Database Disaster Recovery is the process of recovering 
55 the database entities foUowing a catastrophic failure. This 

process should be fully integrated in the enterprise- wide 

disaster recovery plan. 

Database Backup/Restore Management 

Database Backup/Restore Management is the process of 
60 providing point-in-time backup and recovery for logical 

database restores. This includes application-driven data 

errors, dropped tables, and corrupt data. 

Capacity Modeling & Planning 

Capacity Modeling & Planning ensures that adequate 
65 resources will be in place to meet the SLA requirements, 

keeping in mind operational requirements which may 

require additional capacity. Resources can include such 
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things as physical facilities, computers, memory/disk space, 
communicaiioQS lines and personnel. Through this 
component, changes to the existing environment will be 
determined, modeled and planned according to the neces- 
sary requirements. 
Implementation Considerations 
What are some limitations that may be encountered? 

Capacity Planning & Modeling must coordinate the 
requirements across the system (e.g., networks, servers, 
workstations, CPU, etc.) Capacity is driven by the need to 
meet SLAs with the user communities and as pari of the 
planning and modeling process, future threats to capacity 
should be identified. 

Capacity planning cannot, however, be done separately 
for each piece of the system. Capacity planning must be 
done for the system as a whole to understand how the 
capacity of one portion of the system affects the capacity of 
another. Due to the large number of components within a 
distributed environment with any-to-any connectivity that 
will affect the systems capacity, the equation for determining 
capacity quickly becomes large, with many inlerdependen- 
cies. 

Monitoring (1340) 

Verifies that the system is continually functioning in 
accordance with whatever service levels are defined. 
Performance Management 

Performance Management ensures that the required 
resources are available at all times throughout the distributed 
system to meet the agreed upon SLAs. This includes moni- 
toring and managemeat of end-to-end performance based on 
utilization, capacity, and overall performance statistics. If 
necessary. Performance Management can make adjustments 
to the production environment to either enhance perfor- 
mance or rectify degraded performance. 
Implementation Considerations 

What are some of the critical elements to focus on in a 
centralized environment and distributed environment? 

Performance Management in a centralized environment 
typically focuses on three main factors; CPU utilization, 
disk I/O, memory occupancy. 

Within the distributed environments, however, these fac- 
tors extend out into the environment across networks, 
increasing the complexity of gathering the necessary per- 
formance information. 

View performance as a typically business driven? 

Performance Managemeat needs to consider performance 
from a business perspective, not merely a systems one. Most 
transactions in distributed systems utilize a wide variety of 
resources, and the measurement of eod-to-end response time 
becomes the sum of the time expended by each one of the 
components sequentially involved in the transaction less the 
time while components were processing in parallel. 
What devicesAisers will be monitored and at which loca- 
tions? Will this information change? 

Understanding the scope of devices/users, and their loca- 
tions is key to managing performance. Understanding 
whether or not the scope will change will help determine 
how Performance Management needs to be approached. 
Will performance be measured from end-to-end or merely 
for individual components? 

The issues associated with each of these approaches are 
described above. The approach chosen will have a profound 
efifect on determining the issues that need to be resolved. 
Will monitoring be continuous or by demand? 

Continuous monitoring can generate significant perfor- 
mance overhead, whereas targeted, periodic monitoring may 
only be necessary. This strategy will impact the design of the 
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technical infrastructure as well as the tools chosen the 
manage the systems performance. 

Will only selected transactions be measured, and if so, 
should this selection be configurable? 
5 It may be necessary to measure business critical transac- 
tions only; specified within the SLA. If the facility to select 
specific transactions is required, significant customization of 
the system maybe necessary. 

Will response times be required for all transactions of a 
10 particular type, or can sampling be used? 

Once transaction have been selected for monitoring, the 
decision needs to be taken whether or not every transaction 
of that type should be monitored, or only a sample set of 
those transactions. Full monitoring may increase network 
15 and processing overheads. 

The ability to dynamically adjust the system to improve 
performance is also critical? 

As SLAs will likely be tied in some way to performance, 
it is important to monitor and correct the systems perfor- 
20 mance as it degrades to ensure that operational levels are 
maintained and that the SLA(s) will not be violated. 
Product Considerations 
What is the Intended use of the tool? 

Collect, analyze and display in graphical format real-time 
25 performance characteristics from a wide range of resources. 
Analyze current workload and configuration data and fore- 
cast future requirements, as well as providing input into the 
Financial planning process. 
What other utilities are available with the tool? 

Provide real time monitoring and interactive tuning of the 
environment. Ability to input threshold alerting based 
on high/low watermarks and proactively act. 
Monitoring capabilities include the ability to measure 
CPU and disk utiUzation, memory occupancy, transac- 
tion response time, reports (storage & distribution), 
printers, network utilization and performance, circuit 
utilization, backup facilities, WAN/LAN utilization.. 
Instance level tuning and configuration parameters 
40 (memory, I/O, joumaling) to address performance 
problems. 

Other integrated tools needed to provide support for this 
environment? 

May require use of some or all of the following monitor- 
45 ing tools: operating system monitor, on-line monitor, batch 
monitor, data base monitor, (host, server) and network 
monitor (WAN, LAN). 

How well docs the tool integrate and interface with other 
tools/components in the environment? 

^0 Performance measures must be consistent with Service 
Level management techniques 
Performance statistics are essential to facilitate ongoing 

Capacity Planning and Modeling. 
Resource utilization statistics may be used to generate 

costing, and potential billings for customers. 
Passes data to the resource consumption management 
faciUty to report on the recurring processing cost of 
each business application. 
60 Physical Site Management 

Physical Site Management monitors the central and dis- 
tributed sites environmental and regulatory levels. Physical 
Site Management ensures that adequate power, cooling 
facifities, fire suppression, etc. are provided and maintained 
55 to prevent system outages. When necessary, correaive 
actions are issued and monitored according to pre-defined 
environmental control plans. 
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Testing (1342) test of a full business cycle (to show ihal Operations can run 

Ensures that changes to the distributed environment will it) and full business volumes (to show that SLA targets can 

not negatively impact the distributed environment and that be achieved). These tests are, however, expensive in terms 

changes will cause positive things to take place (e.g., better of dedicated hardware requirements, people, and elapsed 

system performance, improved operabilily, etc) 5 time. 

Product Validation practice. Release Planning will propose an approach 

Product Validation tests potential hardware and software dependent on the magnitude and sensitivity of change for 

for the distributed environment prior to procurement to ^^^^ .^j^^^ ^h^ ^ ^^^^j^ ^pprov^d by senior 

determme how wel a product wiU tultill the requirements „,anagement. If service levels are not to be compromised, 

.den ifled. Product Val.dat.on also ensures that the >inple- ^^^^^ ^ ^ 

mentation of a new product wiU not adversely affect the n % - n^AA\ 

existing environment. Keposiiones 

Implementation Considerations Repositories contam all the management data generated 
To what extent will the production environment be managemem process. This includes 
reflected? historical data, capacity data, performance data, problem 
The design of the test environment should reflect the knowledge bases, asset databases, solution sets, and man- 
production environment as closely as possible. In principle agement information bases (MIBs). The repositories com- 
it is desirable to have an identical set up in both environ- ponent interacts with the management applications, integra- 
ments. However, this may be cost prohibitive and some parts tion platform, supporting infrastructure, and presentation 
of the configuration may not be critical to business. The components. Again it is important to make sure that the other 
contents of the test environment therefore need to be 20 components of the operational architecture are compatible 
decided. Yet it is difficult to judge which components of a with the database tools, 
distributed environment may actually impact services. For Production Control (1346) 

example, networking components, such as bridges, are often Ensures that production activities are performed and 

seen as transparent and not required in a test environment, controlled as required and as intended, 

which my mean that several LANs in production are only 25 Backup/Restore Management 

reflected by one LAN in the test environment. The risk of gackup and Restore Management considers all of the 

adoptmg this approach must be addressed thoroughly, and ^ack-up and restorations that need to take place across the 

should be approved be semor management. distributed system for master copies of data. Depending on 

What are some limitations that may be encountered within t^e need, these processes may occur centrally or remotely, 

a distributed environment? Archiving 

Because the technologies are new, it may not be posisible Archiving saves and stores information across the distrib- 

to accurately assess what needs to be tested for a particular ^ted environment, either centrally or in distributed locations, 

product. There are many configuration vanants m the dis- Archiving moves data sets, files, etc. from one device to 

tnbuted environment, a single test environment for the another, usuaUy lower speed, device based on a number of 

validation becomes difficult to achieve and mulUple test 35 parameters. Archiving can be used to move information to or 

environments may be required. distributed and centralized sites. 

Release Testing Integration Platform (1348) 

Release Testing receives the proper version of a release jhe integration platform provides a common platform for 

package (e.g., software, data, procedures, support materials) operational architecture. At the lowest level this means 

and tests the release of the upgrade in a test environment to ^ deciding on common standards, interfaces, massage formats, 

ensure that the: and file logging forms to be used with ail the management 

entire release package is compatible with the existing tools. Lastly, some environments use a home grown inte- 

environment gration platform. The choice of integration platforms 

release package may be released successfully by the depends upon its ability to integrate with the execution and 

planned methods 45 development environments. 

release can be supported by support personnel. Network Management 
Implementation Considerations Network & Systems Management Planning is responsible 
To what extent will the production environment be for the planning activities involved in mnning the day-to- 
reflected? day operations and maintenance of the production systems 

The design of the test environment should reflect the 50 (e.g., capacity planning, performance planning, etc.). 

production environment as closely as possible. In principle Supporting Infrastructure (1350) 

it is desirable to have an identical set up in both environ- The supporting infrastructure is the subset of operating 

ments. However, this may be cost prohibitive and some parts systems, utilities, languages, and protocols used to support 

of the configuration may not be critical to business. The the management of the system. The supporting infrastruc- 

contents of the test environment therefore need to be 55 ture is most often determined by the execution and devel- 

decided. Yet it is difficult to judge which components of a opment environments and the business applications on the 

distributed environment may actually impact services. For system. It is necessary to ensure that the other components 

example, networking components, such as bridges, are often of the operational architecture are compatible with the 

seen as transparent and not required in a test environment, existing supporting infrastructure. This limit s the number of 

which my mean that several LANs in production are only 60 possible tool s et solutions. Examples of operating systems 

reflected by one LAN in the test environment. The risk of include HP-UX, AIX, Solaris, SCO, Novell NOS, MVS, 

adopting this approach must be addressed thoroughly, and Open VMS, NT and DOS. Examples of support utilities 

should be approved be senior management. include PS, GREP, IBCOPY, TAR, CPIO and clock corre- 

Will release tests cover the full business cycle and use full lation . Examples can be broken down according to their 

business volumes? 65 function within the OSl model. Session protocols include 

To ensure that the Operability Principles have been SNMP, CMIP, FTP, and RPC. Transport protocols include 

satisfied, each release should, in principle, undergo a release TCP and UDP. Network protocols include IP and IPX. 
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Data-Link protocols include Token Ring, Ethernet, X.25, 
ATM, SONET, and Frame Relay. 
Production Control (1352) 

Ensures that production activities are performed and 
controlled as required and as intended. 5 
File Transfer & Control 

File Transfer and Control initiates and monitors files 
being transferred throughout the system as part of the 
business processing (e.g., nightly batch runs). File transfers 
may occur between any two or more devises within the lo 
system. 

Implementation Considerations 

What platforms will be involved in the file transfers? 

The platforms will be determined by both the business 
and the technical requirements. This will impact the selec- 15 
lion of the file transfer tools, and, in particular, how the file 
transfers are controlled from platform to platform. 
How many files will be transferred? With what frequency? 

The number of files to be transferred as well as their 
frequency will impact the capacity required on the system 20 
(e.g., network bandwidth) as well as the production sched- 
ule. In addition, if the volume of data is significant, data 
compression may be required. 
Will store and forward be supported? 

Store and forward techniques can help reduce the con- 25 
tention for system resources during business hours. Store 
and forward can also reduce the amount of traffic in the 
system based upon the routing tables defined within the 
system. Instead of having one machine send the same file to 
multiple machines, for instance, a cascading forwarding 30 
mechanism can be used. This also improves the system 
performance as files are sent a minimal number of times to 
certain devices which then forward the files on to other 
devices. 

What are some limitations that may be encountered? 35 

File transfers in a distributed environment are not con- 
fined between hosts. File transfers can take place in a 
bidirectional fashion between hosts, servers and worksta- 
tions. Due to the geographical disparity and number of 
devices in these environments, file transfers will increase the 40 
traffic over the network and will require careful scheduling 
to ensure that the necessary file transfers take place amidst 
the rest of the processing. 
Managing Hardware (1354) 

Managing hardware is all hardware directly used to 45 
manage the environment. This includes all staging compo- 
nents. These components arc devoted to systems manage- 
ment functions. Examples of managing hardware include 
management servers, management controllers, management 
consoles, probes, and sniffers. One significant component in 50 
the hardware monitoring arena is Firewall access control 
policy management. Firewalls are regularly used for net- 
work based security management. It is typically a system or 
group of systems that enforce access control between two or 
more networks and/cr perform network data packet filtering. 55 
Usually packet filtering router hardware and application 
gateways are used to block unauthorized IP packets and 
enforce proxy defined user commands. 
Failure Control (1356) 

Involves the detection and correction of faults within the 60 
system whether they be minor (e.g., workstation is down) or 
major (i.e., a disaster) has occurred. 
Disaster Recovery 

In the event of a significant system failure. Disaster 
Recovery processes will be invoked to re-route the system 65 
resources to a secondary, stable configuration until the 
primary resources can be restored. Within a distributed 



environment, disaster recovery must account for differing 
levels of disaster whether at a central or distributed site(s). 
Fauh Management 

When a negative event has been brought to the attention 
of the system, actions are undertaken within Fault Manage- 
ment to define, diagnose, and correct the fault. Although it 
may be possible to automate this process, human interven- 
tion may be required to perform at least some of these 
management tasks. 
Implementation Considerations 
What are some limitations that may be encountered? 

In order to correct faults in a distributed environment, 
remote fault diagnosis and correction tools may also be 
required. It may not be possible to count on having technical 
expertise on-sites, forcing fault management to be handled 
from a centralized area. Products which perform these 
functions at present, however, provide somewhat limited 
capabilities in this arena. 
Recovery 

Recovery manages all of the actions needed to restore 
service delivery after a system failure. With critical business 
applications being rolled out on distributed technologies, the 
recovery of these systems must be easy, quick and efficient 
to guarantee availability of core business systems as 
expressed in the agreed service levels and operational levels. 
Hardware Maintenance 

Hardware Maintenance maintains all of the components 
within a distributed system to protect the investment of the 
organization. Generally agreed upon in the SLAs, mainte- 
nance contracts are carried out, monitored and recorded for 
each asset as appropriate. 
Implementation Considerations 
What will the Hardware Maintenance targets be? 

Different hardware components will Ukely have different 
maintenance targets. These targets should be defined based 
upon information provided by the vendor as well as infor- 
mation provided firom other client engagements. 
Where will Hardware Maintenance be required? 

Hardware Maintenance may be required at both the 
central and remote locations. Careful consideration must be 
given as to how the hardware at remote locations will be 
maintained (e.g., by a local expert, third- party vendor, etc.) 
Monitoring (1358) 

Verifies that the system is continually functioning in 
accordance with whatever service levels are defined. 
Event Management 

An event is an electronic message generated by any 
component (e.g., application software, system software, 
hardware, etc.) in the system. Event Management receives, 
logs, classifies and presents event messages on a console(s) 
based on preestablished filters or thresholds. 
Implementation Considerations 

What type of events will be monitored? More specifically, 
what services need to be monitored across which devices 
(e.g., servers, workstations, routers, hubs, bridges)? 

The scope of events to be monitored will have a major 
impact on the approach taken for Event management and the 
tools selected. 

Where will devices reside on the network, and how fre- 
quently will they be polled? 

The number of devices, their respective locations and 
polling requirements will significantly contribute to network 
bandwidth usage. 

Where can event filtering be appUed? 

In order to reduce bandwidth, it is preferable that event 
filtering be performed locally to avoid sending aU event 
information across the network, utilizing bandwidth and 
central processing capability unnecessarily. 
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What managemenl protocols Deed to be supported? 

The protocol requirements will impact the selection of the 
tool. For more information on management protocols, refer 
to the management protocols using SNMP and CMIP as 
examples. 

What are some of the limitations that may be encountered? 

The number of events generated in the system will 
increase due to the complexity of the system. Devices will 
generate events as well as applications, the technical 
infrastructure, etc. Common event handling mechanisms 
will be required to provide management information in a 
simple, consistent format and to forward important events 
on for management purposes. In addition, filtering capabili- 
ties may also be needed at remote locations to prevent the 
streaming of events to central/master management consoles. 
Performance Management 

Performance Management ensures that the required 
resources are available at all limes throughout the distributed 
system to meet the agreed upon SLAs. This includes moni- 
toring and management of end-to-end performance based on 
utilization, capacity, and overall performance statistics. If 
necessary. Performance Management can make adjustments 
to the production environment to either enhance perfor- 
mance or rectify degraded performance. 
Physical Site Management 

Physical Site Management monitors the central and dis- 
tributed sites environmental and regulatory levels. Physical 
Site Management ensures that adequate power, cooling 
facilities, fire suppression, etc. are provided and maintained 
to prevent system outages. When necessary, corrective 
actions are issued and monitored according to pre-defined 
environmental control plans. 
Implementation Considerations 

What are some of the limitations that may encountered? 

Important to ensure that adequate power, cooling 
facilities, fire suppression, etc. are provided and maintained 
to prevent system outages from external environmental 
factors. With increased computing power at multiple sites, 
these tasks may not be simple. 
Physical Environment (1360) 

The physical environment includes all the support indi- 
rectly involved in maintaining and managing the distributed 
environment. Initially it was thought client/server technol- 
ogy would make data centers obsolete. However, with the 
migration of mission critical processes to client/server 
environments, many servers are being maintained in data 
centers in an effort to increase reliability. As a result, the 
importance of managing the physical environment has 
increased. Partially because it was initially believed not to be 
very important and because it does not relate directly to the 
information systems, the physical environment of the opera- 
tional architecture is often overlooked. These systems 
include UPS, raised floor, power, site survey and 
preparation, wiring/cabling, cUmate control, etc. 

Related MODE functions The breakdown the MODE 
functions by operational architecture layer is meant to 
provide a guideline. The MODE functions mentioned within 
each component are applicable to that component though the 
function may not be included in that component. For 
example. Physical Site Management relates to the physical 
environment in that the physical environment contains the 
hardware managed through Physical Site Management. 
Physical Site Management tools do not necessarily reside in 
the physical environment layer. Some MODE functions do 
not require the use of a tool, while other MODE functions 
have tool solutions that work in different ways. For this 
reason some functions were included in multiple layers 
while other functions were omitted. 
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Implementing (1362) 

Executes change within the distributed environment with 
tested components and techniques according to the appro- 
priate plan(s). Implementing includes such things as: initial 

5 installation, software & data distribution, license 
management, etc. 
Initial Installation 

Initial Installation prepares the physical location for the 
rollout of a new site or service, pre -assembles the equipment 

10 (hardware and software) based on developed specifications, 
installs the equipment and tests that the equipment is fully 
functional prior to allowing the users to utilize the system in 
a production environment. 
Implementation Considerations 

15 Some guiding principles: 

Precise build procedures must be delivered early enough 
to drive Release Testing, Procurement, and rollout plans. It 
must be clear exactly what the install process will cover. 
Who will perform which tasks when and where? Software 

20 and Data must be available in time to create copies for the 
hangar. This means development teams need to ensure 
availability of software up to a number of weeks before 
going live. 

To what extent will configuration be performed centrally 
25 prior to installation? 

Some of the configuration tasks can be performed in a 

central hangar Assembly of the machines may include 

configuration and software installation. Only minor tasks, 

such as setting networking addresses have to be performed 
30 after the equipment has been delivered to the remote site. 

Product Considerations 

What is the intended use of the tool? 

Prepare physical locations and devices (both FfW and 

SW) for new rollout based on developed specifications and 
35 perform installation and functional testing of new devices 

prior to release to the users. 

What other utilities are available with the tool? 

Initial Installation must be able to load rapidly, reliably 

and consistently a large number of devices with a standard 
40 configuration. Automatic update of asset data accordingly, 

asset inventory must reflect the actual state of the devices; 

their set up and their networking address. 

How well does the tool integrate with other tools in the 

environment? 

45 During Initial Installation, software and data is loaded at 
the machines. The Software & Data Distribution function 
may be used to ship software and data to the location where 
it is to be installed (e.g. remote sites). 
Procurement 

50 Procurement is responsible for ensuring that the necessary 
quantities of equipment (tx)th hardware and software) are 
purchased and delivered on-time to the appropriate loca- 
tions. Procurement is also responsible for logging all assets 
into the inventory as they are received. 

55 Implementation Considerations 

Will Equipment be resourced from multiple or single sup- 
pliers? 

It is likely that organization will have close and long-term 
relationships to certain suppliers. In many cases, suppliers 

60 will offer discounts to their most loyal customers. These 
partnerships are advantageous for both sides, as long as they 
do not lead to supplier lock-in, i.e. the organization becomes 
technically dependent on one supplier. Technical portability 
and interoperability help support independence. 

65 What will be the payment policy (immediate or delayed)? 
A management decision is required, which compares cash 
flow benefits through payment as late as possible against 
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discounts for early payment This will usually be an exten- 
sion of an existing policy. 
Monitoring (1364) 

Verifies that the system is continually functioning in 
accordance with whatever service levels are defined. 
Physical Site Management 

Physical Site Management monitors the central and dis- 
tributed sites environmental and regulatory levels. Physical 
Site Management ensures that adequate power, cooUng 
facilities, fire suppression, etc. are provided and maintained 
to prevent system outages. When necessary, corrective 
actions are issued and monitored according to pre-defined 
environmental control plans. 

Although only a few embodiments of the present inven- 
tion have been described in detail herein, it should be 
understood that the present invention may be embodied in 
many other specific forms without departing from the spirit 
or scope of the invention. Therefore, the present examples 
and embodiments are to be considered as illustrative and not 
restrictive, and the invention is not to be limited to the details 
given herein, but may be modified within the scope of the 
appended claims. 

What is claimed is: 

1. A method for managing a development environment in 
a development architecture framework comprising the steps 
of: 

(a) managing service to a developer of the development 
environment based on at least one of service level 
agreements with the developer and operations level 
agreements with the developer; 

(b) performing a plurahty of system management opera- 
tions on the development environment selected from 
the group of system management operations consisting 
of start-up and shut-down operations, back-up and 
restore operations, archiving operations, security 
operations, and performance monitoring operations; 
and 

(c) plaiming service to the developer in order to anticipate 
and implement changes in the development environ- 
ment. 

2. A method as recited in claim 1, wherein the step of 
planning service to a developer is carried out by service 
planning tools including at least one of performance mod- 
eling tools and capacity modeling took. 

3. A method as recited in claim 1, wherein the start-up and 
shut-down operations are performed with the start-up and 
shut-down operations being automated. 

4. A method as recited in claim 1, wherein the archiving 
operations are performed to transfer data between different 
mediums with different compression ratios. 

5. A method as recited in claim 1, wherein the perfor- 
mance monitoring operations are performed to determine if 
resources of the system are sufficient to meet a desired 
performance level. 

6. A computer program embodied on a computer readable 
medium for a development environment in a development 
architecture framework comprising: 

(a) a code segment that manages service to a developer of 
the development environment based on at least one of 
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service level agreements with the developer and opera- 
tions level agreements with the developer; 

(b) a code segment that performs a plurality of system 
management operations on the development environ- 

^ ment selected from the group of system management 
operations consisting of start-up and shut-down 
operations, back-up and restore operations, archiving 
operaUons, security operations, and performance moni- 
toring operations; and 

(c) a code segment that plans service to a developer in 
order to anticipate and implement changes in the devel- 
opment environment- 

7- A computer program as recited in claim 6, wherein the 
15 code segment that plans service to a developer is carried out 
by service plantiing tools including at least one of perfor- 
mance modeling tools and capacity modeling tools. 

8. A computer program as recited in claim 6, wherein the 
start-up and shut-down operations are performed with the 

20 start-up and shut-down operations being automated. 

9. A computer program as recited in claim 6, wherein the 
archiving operations are performed to transfer data between 
different mediums with different compression ratios. 

10. A computer program as recited in claim 6, wherein the 
25 performance monitoring operations are performed to deter- 
mine if resources of the system are sufficient to meet a 
desired performance level. 

11. A system for managing a development environment in 
a development architecture framework comprising: 

(a) logic that manages service to a developer of the 
development environment based on at least one of 
service level agreements with the developer and opera- 
tions level agreements with the developer; 

(b) logic that performs a plurality of system management 
operations on the development environment selected 
from the group of system management operations con- 
sisting of start-up and shut-down operations, back-up 
and restore operations, archiving operations, security 
operations, and performance monitoring operations; 
and 

(c) logic that plans service to tt^ developer in order to 
anticipate and implement changes in the development 
environment. 

45 12, A system as recited in claim 11, wherein the logic that 
plans service to a developer is carried out by service 
planning tools including at least one of performance mod- 
eling tools and capacity modeling tools. 

13. A system as recited in claim 11, wherein the start-up 
50 and shut-down operations zire performed with the start-up 

and shut-down operations being automated. 

14. A system as recited in claim 11, wherein the archiving 
operations are performed to transfer data between different 
mediums with different compression ratios. 

55 15. A system as recited in claim 11, wherein the perfor- 
mance monitoring operations are performed to determine if 
resources of the system are sufficient to meet a desired 
performance level. 

* * ♦ ♦ * 
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